Reducing the Standards Track to Two Maturity Levels
RFC 6410

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

Comment (2011-09-02)
No email
send info
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 

    “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 [1]?


(Dan Romascanu) Yes

(Peter Saint-Andre) (was Discuss) Yes

(Robert Sparks) Yes

(Sean Turner) Yes

Comment (2011-06-07 for -)
No email
send info
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 email
send info
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 [1] 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

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.

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

(Adrian Farrel) No Objection

(David Harrington) No Objection

(Pete Resnick) (was Discuss) No Objection

(Russ Housley) Recuse