Mark Atwood <mra(_at_)pobox(_dot_)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 <mrex(_at_)sap(_dot_)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 <john(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf