Re: Discussion of draft-hardie-advance-mechanics-00.txt

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

 



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


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