Re: call for ideas: tail-heavy IETF process

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>>>> "Sam" == Sam Hartman <hartmans-ietf@xxxxxxx> writes:
    Michael> If we are unwilling to bring "RFC" back to a place were it
    Michael> does not equal STD, then we need to create a new category
    Michael> of document which amounts to "fully baked ID".  Things like
    Michael> IANA allocations could occur at that point.

    Sam> Hi.  Could you clearly articulate why you want this category and what
    Sam> you hope it will do and not do?  I tried to respond with my thoughts
    Sam> about this but realized that I don't understand your goals well enough
    Sam> to provide more than a poorly considered reaction.

It's what Carsten said.

1) this idea is baked enough for cross-area review to make sense.
2) the protocol is not going to change significantly, one could
   implement.
3) any future changes need thus to take into account impact on
   existing implementations... BUT that doesn't mean that we can't
   change things.

It's what PS *ought* to have been, and what "RFC"s were prior to
1990 or so.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@xxxxxxxxxxxx  http://www.sandelman.ca/        |   ruby on rails    [ 
	

Attachment: pgpMDTJFUrIBu.pgp
Description: PGP signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]