Reply to your request 12.04.2013 Reviewer: Abdussalam Baryun (AB), Date: 26.04.2013 Sub: comments for I-D: draft-sheffer-running-code-04 ++++++++++++++++++++++++++++++++++++++ The participant reviewer supports the document, very interesting and helpful, my recommendations and comments below, Overall Comment> IMHO, we should not request to delete this proposed section, but it can be shifted to the Appendix section when published. Removing the section is like doing some work in IETF and then destroying it, future reviewers/implementers may not know why it was accepted to publish or be implemented. If I read a document from the past/present I would like to know its usefulness to increase my acceptance. I-D Introduction> Some of them may never get implemented. AB>amend> Some of them may never get implemented or used. We implement a specification for a use case or to be used within another specification, some specification may have available to use another but never does use the other (was that a waste of running code, or may that be used by an attacking specification). I-D Section 2> AB> I will add points: o the date of implementation. o the reason for implementation, or use-case targets. AB>Quest> Why before security consideration? I recommend it to be after all sections, because implementors consider that security section within their work and may refer to it. The security consideration section is for the specification documented, not including the implementation issue. If you code something it may be used to test security issues for such specification use case (so we consider that info in the section proposed). Section 3> AB> Add> the WG may replace it into a historical document that can be refered to by the current concerned WG document, Section 5.1> 18 Months AB> The duration is not understood if it is maximum or minimum requirement. Please provide the requirement language to be clear. (I don't know from where the 18 came from, I like to specifying *three IETF WG meeting* presentations/discussions of such implementations. If you don't present/discuss the implementation inside IETF then how do we document such work/activity? AB>Comment> in one WG it was said that some companies don't want to discuss their implementations or results. Is it strange to *use* the IETF specification and not report back to it for future progress of such document? Section 5.2> If this idea is adopted by document authors, a summary I-D will be written containing the statistics of such adoption, as well as (necessarily subjective) reports by working group chairs and area directors who have used this mechanism. AB> Amend>If this idea is adopted by the document editors and WG (if was a WG document), a summary I-D will be written containing the statistics of such adoption, as well as (necessarily subjective) reports by working group chairs ((if was a WG document) and area directors who have used this mechanism. AB> comment> I hope we don't ignore the WG decisions, some day we will have only chairs and directors discussing in meetings or on the list, Regards Abdussaam On 4/12/13, The IESG <iesg-secretary@xxxxxxxx> wrote: > > 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. > > >