ietf
[Top] [All Lists]

Re: Last Call: <draft-sheffer-running-code-04.txt> (Improving Awareness of Running Code: the Implementation Status Section) to Experimental RFC

2013-04-26 01:27:10
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(_at_)ietf(_dot_)org> 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(_at_)ietf(_dot_)org mailing lists by 2013-05-10. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)org 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.




<Prev in Thread] Current Thread [Next in Thread>