Ted Hardie <ted.ietf@xxxxxxxxx> wrote: > > Title: Proposed mechanics for document advancement > Author(s): T. Hardie > Filename: draft-hardie-advance-mechanics-00.txt I seem to have been inordinately busy recently: sorry to take so long getting around to this. Ted has correctly identified the problem as "mechanics for advancement," but IMHO has written a design for how to win the last war... :^( (He also got some details wrong, but those aren't so important.) We have a long-standing situation where three "maturity levels" have been designed and documented in an IETF-consensus document (RFC 2026) which has proven remarkably resistant to change. And we have a current effort at changing it which perpetuates the frankly wrong-headed idea that the problem is that we got the number of levels wrong. Thankfully, Ted has correctly noted that that's _not_ where the problem lies. I'm going to put on a hat I very seldom wear when I post to this list -- the hat of a Narrative Scribe for IESG telechats. I've listened to the process of trying to advance maturity levels of email-related documents. It's painful! No, it's _very_ painful! The IESG has a process for standard-track documents, which has evolved to match the world-as-we-know-it. Basically, it formalizes LastCalls; then proceeds to a shepherding process where one AD tries to get consensus of the whole IESG that the document is "a reasonable basis on which to build the salient part of the Internet infrastructure." Any other AD may call for discussion during a telechat. (Alas, the agendas are so full that merely placing a DISCUSS doesn't mean that.) In general, ADs write either a DISCUSS or a COMMENT; and a DISCUSS is (initially) blocking: the sponsoring AD must look for a way to "resolve" the DISCUSS. Sometimes this is simple clarifying language; sometimes it's not so simple... I have listened while agenda items related to advancing "maturity" of email standards came up. It has been confusing, not only to me, but to various IESG members as well. I've also been subscribed to mailing-lists such as <ietf-smtp>. The folks on those lists are even more confused, and black helicopters are frequently sighted. :^( Nobody seems to know quite what the IESG is supposed to do when it considers a document for "advancement in maturity" (except John Klensin, of course!) -- and IMHO that is the source of the confusion and pain. What we need, IMHO, is not a revision to RFC 2026, but a procedure which eliminates the confusion and pain. And John Klensin was definitely on the right track when he wrote his ISD draft (draft-ietf-newtrk-repurposing-isd) calling for "Internet Standards Documents" to track maturity, etc. of standards-track RFCs. (I don't claim it was perfect -- indeed I co-authored a different proposal intended to seriously minimize the IESG involvement in writing such documents.) The essential point is that "advancement in maturity" should _not_ involve the IESG in a review de nova; but merely document the implementation and deployment history. IMHO, John Klensin is much closer to the right solution to this issue than Ted Hardie: Ted spends too much effort aiming for consensus in things which shouldn't matter, while John sets out to document things about which there's not a whole lot of room for disagreement. So, to recap, I give Ted Hardie high marks for identifying the problem, but John Klensin higher marks for proposing a way forward. -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf