Reducing the Standards Track to Two Maturity Levels
Note: This ballot was opened for revision 09 and is now closed.
(Jari Arkko) Yes
(Ron Bonica) Yes
(Wesley Eddy) Yes
(Stephen Farrell) (was No Objection) Yes
I'm changing to Yes on this based on the recent mails to ietf-discuss. I continue to think there is rough consensus for 2 levels but am motivated to move to a Yes by the arguments of those against moving to 2 levels which appear to me indistinguishable from obfuscation. (Which could be deliberate or a side-effect of some honestly held opinion, its not really possible to say.) This is such a boring topic that a funny quote seems worthwhile: “A Frenchman once tried to obfuscate me from behind. Although I protested out of sheer principle, I must confess that I thoroughly enjoyed it.” ~ Oscar Wilde on Obfuscation I think the always-reliable Oscar's quote is as relevant as the objections to 2 levels that I've seen so far. My original comment was: I still don't know from reading this if STD numbers will be allocated for "Internet Standard" RFCs. I don't mind if they are or not, but confusion about it doesn't seem good. For example, what'll happen to ?  http://www.rfc-editor.org/rfcxx00.html#STDbySTD
(Dan Romascanu) Yes
(Peter Saint-Andre) (was Discuss) Yes
(Robert Sparks) Yes
(Sean Turner) Yes
Comment (2011-06-07 for -** No value found for 'p.get_dochistory.rev' **)
Section 2 contains the following: Experience with a Proposed Standard often leads to revisions that clarify, modify, enhance, or remove features. Review of revisions to a Proposed Standard that is submitted for publication at the same maturity level is generally limited to the changes. Perhaps r/the changes/these types of changes ? RFC 5967 already updates RFC 2026, but a reference to RFC 2026 in Section 2.2 would be helpful to those writing implementation reports.
(Stewart Bryant) No Objection
Comment (2011-06-22 for -** No value found for 'p.get_dochistory.rev' **)
nit - Introduction "This document proposes several changes " should presumably be "This document makes several changes " I am concerned about the following: "Note that the distinct requirement from RFC 2026  for reports of interoperability testing among two or more independent implementations is intentionally subsumed by the requirement for actual deployment and use of independent and interoperable implementations." We really need to consider defining "independent". NTP is a good illustration of the problem - there are lots of boxes out here that run NTP which some may perceive as independent implementations. However they all seem to run the code written by Dave Mills' project arguably making them a single implementation. Since we touching on the subject we should clarify what we mean by "independent" give the existence of open source.