Mark Atwood <m...@pobox.com> 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 <m...@sap.com> 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 <j...@jlc.net> _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
