Hi AB, Thanks for your review. > 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. There are two points related to this. The first is that the intent of the information is to enable the WG/community/IESG make a better assessment of the maturity and stability of the specification while advancing it through WG last call to RFC publication. Thus, once publication has been agreed, the information has served its purpose and can be dropped. The second point is that the information is likely to become obsolete very quickly. So, while there *is* marginal value in retaining the information that was true at the time of publication of an RFC, it is unclear that it provides great value. If the authors/WG consider that a living record of implementation of RFCs is valuable, if would be better to move this to a wiki. That, however, is beyond the scope of our I-D. > 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 take your point, although I think it is rare for people to implement code without intending to execute it. > I-D Section 2> > > AB> I will add points: > o the date of implementation. > o the reason for implementation, or use-case targets. Would be useful information if people are willing to state it. > 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. Funny! Got to put the section somewhere. My preference is for it to be in the same place in all documents. Have had several responses suggesting different places to put the section. I can't get excited about where it should go. Yaron and I will discuss moving it. > Section 3> > AB> Add> the WG may replace it into a historical document that can be > refered to by the current concerned WG document, Do you mean a historical RFC? I suppose this option is open to the WG if they want to go that way. for the reasons stated above, I would think that a poor idea. > 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? This is the period during which the authors will conduct the experiment. At the end of this period the authors will report to the community. Why 18 months? Because that is what we think feels right given how long it takes to advance I-Ds. Should implementation status be presented at IETF meetings? That is entirely up to the WGs and the individuals involved. I am entirely uninterested in sitting through marketing presentations at IETF meetings. I have no objection to seeing a slide that reports on the current implementations status per the latest revision of an I-D - but I can't understand why people wouldn't just read the I-D to find out this information. > 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? Such is the world of business. Adrian