Re: draft-housley-two-maturity-levels

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

 



Mark Atwood <mra@xxxxxxxxx> wrote:
> 
> This post would be much less confusing if you would name names, cite
> examples, and point fingers.

   No, it wouldn't.

   We don't need a flame-war over which features of which protocols
would have to go away under a strict reading of RFC 2026 in order to
advance.

   The point is clear enough: that features that find their way into
Proposed Standards have constituencies, and that pulling them out is
too painful for most WGs to tackle.

> [Martin Rex <mrex@xxxxxxx> wrote:] 
>
>> The reason why so many documents are at proposed is that they're
>> often collections of bloat (limited-use features with an aggresive
>> requirements level) from various interest groups that is
>> not strictly necessary for a protocol to be useful, and sometimes
>> used only by a minority.

   Thank you, Martin!

   This brings us closer to the actual problem.

>> Normally, for progression from Proposed to Draft,
>>
>> - some of the MUSTs would have to be changed to SHOULDs,
>> - some of the SHOULDs would have to be changed to MAYs,
>> - some parts might better be moved to seperate, optional
>>   extensions documents

   I've been there, done that, got the T-shirt. Some pretty dreadful
MUSTs remain because of constituencies. "Consensus" is reached only
by exhaustion.

   Often we end up leaving stuff which can reasonably be called "bloat"
(though that's not how I would describe it) because we can't reach
agreement that we can patch-in a better way without "recycling at
Proposed".

   The whole process is exhausting. More often than not, folks give up.

>> But the particular interest groups would rather have the document
>> remain at Proposed than seeing any of the requirements level of
>> those particular features they're interested in, to come out lowered,
>> or see features removed from the base protocol and into a
>> seperate extensions document.

   Remaining at Proposed just doesn't seem that bad after you've been
through the wringer a few times. (It's not that people start out
wanting to prevent progression; it's that consensus on needed changes
is too hard to reach.)

   Add to this that chartering a WG to advance from Proposed to Draft
never seems to happen (what AD would volunteer to endure this _again_?)
and we have the wrangling which should be contained in a WG arising
during IETF LastCall: few document authors will persist long enough.

   I refuse to argue how many levels there should be -- though I'd
be happy to work within the old consensus for three. What needs work
(assuming we aim for more than one) is how to get there from here!
I have some ideas; but the time just doesn't seem ripe to discuss them.

--
John Leslie <john@xxxxxxx>
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


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