Improving Awareness of Running Code: The Implementation Status Section
RFC 6982

Note: This ballot was opened for revision 05 and is now closed.

(Jari Arkko) (was Discuss) Yes

Comment (2013-05-30 for -05)
No email
send info
This is a very good proposal and want to see it adopted. Thank you for writing it. (I share the opinion in comments from Stewart that a pointer to the wiki would be a better option though.)

(Richard Barnes) Yes

Comment (2013-05-29 for -05)
No email
send info
EDIT: It has been pointed out to me that the document actually says to remove the Implementation Status section before going to RFC (end of Section 2).  Alright then, carry on!   Nonetheless, it might be helpful to note that this sort of information can also be useful after an RFC is published, so authors should consider moving the Implementation Status section to some other place (e.g., a web page or wiki) before it disappears at publication.

(Was: I think this is a fine experiment.  But I also think that an RFC is completely the wrong place for this sort of information.  Partly because of the points Stewart raises, but mainly because implementation status can be very dynamic information.  So if you put it in an RFC, it's virtually guaranteed to become stale, especially if the RFC is successful!  It would be better to figure out a way to express this stuff in a more dynamic medium (e.g., a wiki) that could be referenced from an RFC in a standard way.)

(Stephen Farrell) Yes

(Brian Haberman) Yes

Barry Leiba Yes

Comment (2013-05-22 for -05)
No email
send info
A fine idea, which I thoroughly support.

(Pete Resnick) Yes

(Sean Turner) Yes

Comment (2013-05-27 for -05)
No email
send info
Is it worth noting that if this section is in the main body of the specification that the section should be marked as informational?  Likely that the preamble that's there is enough, but maybe worth a thought.

(Stewart Bryant) (was Discuss) No Objection

Comment (2013-06-02)
No email
send info
Thank you for addressing my concern.

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2013-06-03)
No email
send info
Thanks for the new draft version.

- I could live with your proposed change addressing my DISCUSS:

   As a result,
   we do not envisage changes to this section after approval of the
   document for publication, e.g. the RFC Errata process does not apply. 

However, based on my recollection of the IESG telechat discussion, I had it a stronger message in mind:
   As a result, changes to this section after approval of the
   document for publication should not be permitted, e.g. the 
   RFC Errata process does not apply. 

- 
OLD:
   Working group chairs are requested to ensure that this section is not
   used as a marketing venue for specific implementations

NEW:
   Document shepherd and working group chairs are requested to ensure that this section is not
   used as a marketing venue for specific implementations

Justification: after the document left the WG, the document shepherd is responsible for the document, not the WG chairs ... even if we all know that the two functions overlap in most cases.

(Spencer Dawkins) No Objection

Comment (2013-05-28 for -05)
No email
send info
I'm fine with putting this into practice. 

I have one non-blocking request - Is it possible to call this "something besides an experiment" in the draft? (A "proposal"? An "invitation"? an "exploration"?)

I'm sorry for the late surprise. I sent e-mail multiple times about the RFC 3933-ness of Stephen's Fast-Track draft, but don't see that I was equally vocal about this draft. 

My point in sending those e-mails was to say "if you don't need to change BCP text, don't do this as an RFC 3933 process experiment, because RFC 3933 process experiments are still somewhat heavyweight, so you only do one when you need to change BCP text". 

That got heard. This draft isn't an RFC 3933 process experiment, and it says so.

My concern is that the proposal is still described as some variation of "an experiment" about 15 times, RFC 3933 is even listed as a reference, and the draft doesn't say "and by the way, this isn't an *RFC 3933 process* experiment" until about the ninth time the proposal called an experiment.

If it's too late to do anything else, perhaps this point could be moved earlier in the draft.

I am hoping that (with Martin's agreement) we do some actual RFC 3933 process experiments in TSV during the shorter of (the next two years | Spencer being recalled), and I'd like for the community to understand what that means when we put one into place. It is difficult enough to do process change without confusing the community about how that change will be carried out.

I recognize that "an experiment" != "an RFC 3933 process experiment", but if I tried to publish a "proposal for a standardized protocol" that mentioned about halfway through the spec that I didn't mean "an RFC 6410 proposed standard", I hope somebody would object!

(Joel Jaeggli) No Objection

Comment (2013-05-28 for -05)
No email
send info
Not sure that there's any paritcular reason to propose a time limit given the non-mandatory status. if it falls into disuse or is wildly successful then I suppose something can be done about either of those cases.

(Ted Lemon) No Objection

(Martin Stiemerling) No Objection

(Adrian Farrel) Recuse