Re: call for ideas: tail-heavy IETF process

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

 



 In your previous mail you wrote:

>  If we are unwilling to bring "RFC" back to a place were it does not
>  equal STD, then we need to create a new category of document which
>  amounts to "fully baked ID".  Things like IANA allocations could occur
>  at that point.

=> IMHO the last point (IANA allocations) is a critical detail.

>  In the days of dot-boom it was not unusual to see widespread
>  implementation very early in the ID process and even interop and
>  experimental deployment.   While this still occurs for quite a number of
>  things (and sometimes it's a problem that the ID can not be changed as a
>  result), there is an equal amount of "wait for the RFC to come out".

=> as an implementor of early specs I very often get a problem with
the to-be-done IANA allocations: if it is not a concern for a lab
prototype, I enforce the strict policy to *never* make an official
distrib with support, etc, using not officially allocated by IANA
code points. I believe I have not to explain the reason of this policy.
Note this concern does not go very well with the "running code" principle,
this is why I'd like to see Jarri's issue solved, even currently I
don't agree (or disagree) with Michael's proposal.

Thanks

Francis.Dupont@xxxxxxxxxx

PS: I like the SIRS idea even the gen-art review team (which can be seen
as a lightweight prototype of it) can lead me to believe it won't happen
in the real world (i.e., I'd like to be wrong :-), mainly because it
supposes an amount of skilled manpower we don't have.




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