Greetings, all, The idea put forth in this document seems quite useful, and the scope is appropriate for a process experiment, so I support its publication. I have only one comment on the content. In applying this to my own documents and WGs, I'd tend to prefer the "alternate" mechanism described in section 3, even without any of the conditions there necessarily applying. A single reference to a more-easily updatable source like a wiki seems, in general, to be easier to manage than a section in a document which may have an irregular update schedule, especially as revision N of a document will necessarily report on the status of non-author implementations of the protocol as of revision N-1 or before. As the section is designed to be removed before publication anyway, there's no issue with references to sources without proper change control in the resulting RFC, and some WGs/communities may find it useful to keep the implementation status portion of the wiki up and current even after publication. So I'd reverse the sense of "preferred" and "alternate" here, though that's probably just a matter of personal taste. In any case, this is an experiment, so we should try out both inline implementation status and implementation status by-reference, and see which works best in which situations. Best regards, Brian > -----Original Message----- > From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce- > bounces@xxxxxxxx] On Behalf Of The IESG > Sent: 12 April 2013 22:57 > To: IETF-Announce > Subject: Last Call: <draft-sheffer-running-code-04.txt> (Improving Awareness of > Running Code: the Implementation Status Section) to Experimental RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Improving Awareness of Running Code: the Implementation Status > Section' > <draft-sheffer-running-code-04.txt> as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@xxxxxxxx mailing lists by 2013-05-10. Exceptionally, comments may be > sent to iesg@xxxxxxxx instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a simple process that allows authors of > Internet-Drafts to record the status of known implementations by > including an Implementation Status section. This will allow > reviewers and working groups to assign due consideration to documents > that have the benefit of running code, by considering the running > code as evidence of valuable experimentation and feedback that has > made the implemented protocols more mature. > > The process in this document is offered as an experiment. Authors of > Internet-Drafts are encouraged to consider using the process for > their documents, and working groups are invited to think about > applying the process to all of their protocol specifications. The > authors of this document intend to collate experiences with this > experiment and to report them to the community. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-sheffer-running-code/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-sheffer-running-code/ballot/ > > > No IPR declarations have been submitted directly on this I-D.