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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf