Re: draft-housley-two-maturity-levels

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

 



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
_______________________________________________
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]