Ballot for draft-sheffer-rfc6982bis
Yes
No Objection
Note: This ballot was opened for revision 01 and is now closed.
Editorial OLD: We recommend that the Implementation Status section should be removed from Internet-Drafts before they are published as RFCs. 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. NEW: We recommend that the Implementation Status section should be removed from Internet-Drafts before they are published as RFCs. As a result, we do not envisage changes to this section after approval of the document for publication, while the document sits in the RFC-editor queue, e.g., the RFC errata process does not apply. Editorial: OLD: The inclusion of Implementation Status sections in Internet-Drafts is not mandatory, but the authors of this document wish to encourage authors of other Internet-Drafts to try out this simple mechanism to discover whether it is useful. NEW: Justification. We passed the experimentation phase already (no need to try out this simple mechanism to discover whether it is useful), this is now a BCP. Also, this is already covered by: This process is not mandatory. 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.
I have a question and a comment. I noticed that one item missing from the list in Section 2 is a link to the implementation itself, if available. I guess this is sort of implied by the collection of the rest of the other elements listed, but seems like a strange omission nonetheless. Is there a reason for it not to be listed? I understand that this is the same text from RFC 6982. I realize that documenting implementation status in the way this document recommends is better than some alternatives (like not documenting it, or doing so haphazardly), but I'm not convinced that this really is the best way to feed implementation status information into the IETF process and vice versa. At a minimum a wiki where implementors can make their own updates seems preferable to a document controlled by its authors, yet the wiki option here is described as an alternative rather than the default approach.
I agree with Alissa's comment about wikis, etc. In addition to her reasoning, I think the wiki alternative has the advantage (mentioned in the draft) of preserving the information after RFC publication. Perhaps it would be useful to suggest that, when the implementation status is removed from an RFC at publication, it be preserved (and hopefully maintained) _somewhere_, whether a wiki or something else.
* There are two fields I would have liked to see added into the implementation status section. 1) A datestamp for each implementation to denote when the implementation was added to the draft or was last updated (to determine freshness) 2) Draft version number that was implemented (as drafts can change significantly during the wg process) I also agree with Alissa's and Ben's comments about the use of wikis.