Re: draft-housley-two-maturity-levels

[SM <[e-mail]>]

Hello,

At 11:36 25-10-10, Russ Housley wrote:
>Should I be seeking a sponsor for this draft?

I ask for your indulgence as I could not resist:

  "If you wish to seek Area Director sponsorship for an
   individual submission, the best solution is to contact the
   most relevant Area Director directly, with an explanation of
   why the draft is appropriate for IETF publication."

  "Also, please consider the normal IETF publication path
   through an existing working group, or consider proposing
   a BoF at a future IETF meeting."

In Section 1 of draft-housley-two-maturity-levels-02:

  "In the current environment, many documents are published as Proposed
   Standards and never advance to a higher maturity level.  Over time,
   this has resulted in IETF working groups and IESG members providing
   much more scrutiny than is called for by RFC 2026 [1] prior to
   publication as Proposed Standard."

Quoting a message from James M. Polk [1]:

  "I'm not in love with the 3 maturity levels, especially when I was asked by
   an AD during Maastricht to provide proof of 2 independent implementations
   just to have an ID I was presenting be considered to become a WG item."

That does not sound like IESG members providing much more 
scrutiny.  It sounds more like an undocumented rule being applied by 
IESG members.  A clarification about this has been posted [2].

Quoting the message:

   "If there were two independent implementations, this would
    clearly demonstrate the implementability of a Spec."

It is not a stretch too far to say that people will take that case 
and read it as a rule.

In Section 1:

  "One desired outcome is to provide an environment where the IETF
   community is able to publish Proposed Standards as soon as rough
   consensus is achieved."

That lowers the bar from "consensus" to "rough consensus" instead of 
setting consensus as the end-goal and falling back to rough consensus 
if people "agree to disagree".

In Section 2:

  "The requirements for Proposed Standard are unchanged; they remain
   exactly as specified in RFC 2026."

Does that mean that IESG members will not ask for two independent 
implementations?

In Section 5:

   "Lack of this review has not revealed any ill effects on the
    Internet Standards Process."

That means that evaluating the viability of the standardization 
effort and the usefulness of the technology is not important.

In Section 6:

   "The rules that make references to documents at lower maturity
    levels are a major cause of stagnation in the advancement of
    documents."

I would be grateful if anyone could point me to specific cases of 
that which could not have been addressed under current rules.

One of the bottlenecks of the process is the IESG.  It is not 
practical to ask IESG members to do a line by line review of hundreds 
of pages of Internet-Drafts before each IESG evaluation.  The number 
of Internet-Drafts seeking to attain Gold (proposed) Standard is 
quite high.  This proposal cannot change that.

The issue of timeliness of specifications has been mentioned.  If the 
actual specification is going to be delivered in two years or more, 
people will fall back to the Internet-Draft whatever the IETF 
says.  If the IETF is concerned about the IETF Standards Process, it 
could consider whether that can be brought down to one year.  This 
might entail:

  (i) one month for discussing what problem the author is trying to solve

  (ii) one month to haggle about process details

  (iii) nine months to go from Internet-Draft to Last Call

Review the document in a year, nit pick on it and refine it.  The 
IESG can ask for the implementation report at that stage.  Turn Draft 
into where the IETF tries to get it right.  The author would have 
some less than painful experience of the process by then to handle 
this.  The last stage could be seen as documents that have withstood 
the test of time.  If the Internet did not crash by then, the 
document is good enough.

The above is to encourage a "do or die" approach and leave it up to 
the community to go and write code to keep the IETF label.  It is 
infeasible to have IESG members catch all the bad ideas that are 
submitted for evaluation.  The IETF cannot protect the Internet.

   "The benefit of a standard to the Internet is in interoperability -
    that multiple products implementing a standard are able to work
    together in order to deliver valuable functions to the Internet's
    users."

The IETF could turn quality into:

    "the ability to express ideas with enough clarity that they
     can be understood in the same way by all people building
     systems to conform to them, and the ability (and willingness)
     to describe the properties of the system well enough to
     understand important consequences of its design, and to ensure
     that those consequences are beneficial to the Internet as a whole."

As mentioned in RFC 3935:

   "A part of being relevant is being timely - very often, documents
    delivered a year after core decisions have been taken are far
    less useful than documents that are available to the
    decision-makers at decision time."

As nothing has changed since the year 2004, it would be disingenuous 
to place the blame on the current IESG.

At 13:01 26-10-10, Hadriel Kaplan wrote:
>solve a problem anyone has.  For example, I don't think being at 
>only PS has prevented anyone from deploying HTTP or the myriad of 
>other protocols at PS level.  At this point, going above PS is for masochists.

The HTTP RFC is at Draft Standard level.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg64201.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg64298.html