Skip to main content

Improving Awareness of Running Code: The Implementation Status Section
draft-sheffer-running-code-06

Yes

(Brian Haberman)
(Pete Resnick)
(Stephen Farrell)

No Objection

(Gonzalo Camarillo)
(Martin Stiemerling)
(Ted Lemon)

Recuse

(Adrian Farrel)

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

Barry Leiba Former IESG member
Yes
Yes (2013-05-22 for -05) Unknown
A fine idea, which I thoroughly support.
Brian Haberman Former IESG member
Yes
Yes (for -05) Unknown

                            
Jari Arkko Former IESG member
(was Discuss) Yes
Yes (2013-05-30 for -05) Unknown
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.)
Pete Resnick Former IESG member
Yes
Yes (for -05) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (2013-05-29 for -05) Unknown
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.)
Sean Turner Former IESG member
Yes
Yes (2013-05-27 for -05) Unknown
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.
Stephen Farrell Former IESG member
Yes
Yes (for -05) Unknown

                            
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2013-06-03) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-05-28 for -05) Unknown
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-05-28 for -05) Unknown
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!
Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2013-06-02) Unknown
Thank you for addressing my concern.
Ted Lemon Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Adrian Farrel Former IESG member
Recuse
Recuse (for -05) Unknown