Document: draft-dusseault-impl-reports-02
Reviewer: Vijay K. Gurbani
Review Date: Jun 17, 2009
IETF LC Date: June 18, 2009
IESG Telechat date: N/A

Summary: This draft is ready for publication as a BCP; some minor issues and nits below.

The draft has 0 major issues, 3 minor issues, and 8 Nits/Editorial comments.

A general question I had is whether this report guidance is only for documents moving from Proposed to Draft standard and not from Draft to Internet standard?  Certain passages and text in the draft appear to reflect the former scenario (i.e., this guidance is good only for moving drafts from Proposed to Draft standard) however the title of the draft does not seem to restrict it to only this scenario.

Minor issues:
1) In S2, page five, first "Note", it says that "Independent
  implementations should be written by different people at
  different organizations using different code and
  protocol libraries."

  While all else is fine in the text above, why the inclusion
  of different "protocol libraries"?  Sometimes, a protocol
  library is as much critical to a code base as it is complex
  (think OpenSSL).  As such, if implementation A uses
  OpenSSL but its SIP transaction engine code is different than
  implementation B's, which also uses OpenSSL, then these
  two implementations are independent despite sharing a protocol
  library (OpenSSL).

  If we position the criteria as "Independent implementations
  should be written by different people at different
  organizations using genetically dissimilar code base", do we
  loose something in the process?

2) In S2, it is stated that each report "MUST identify the author
  of the report, and in S3 it says that "Titles of implementation
  reports are strongly RECOMMENDED to contain one or more RFC
  number ..."

  This is good advice, however, it is ignored when, in S3, a simple
  outline for a minimal implementation report is given.  I would
  suggest that the outline begin with:

  TITLE: Implementation report for RFC-XXXX
  AUTHOR: Joe Q. Public-Shepherd <joe@example.com>

3) S5.5 is interesting.  Sometimes, the test suites do not even
  appear in the protocol document itself.  Case in point is SIP.
  RFC3261 uses X.509 certificates in TLS, but the test cases for
  how these certificates are to be formed and verified are
  actually in other documents (see S8 and Appendix A and B of
  http://tools.ietf.org/html/draft-ietf-sipcore-sec-flows-00, for
  instance.)

  I do not know what to suggest here, except that you may
  consider using this as an additional example if you think it is
  appropriate.

Nits:

1) S1, consider the following text:

     Moving standards along the standards track can be an important
     signal to the user and implementor communities, and the
     process of submitting a standard for advancement can help
     improve the standard or the quality of implementations that
     participate.

  There is an overuse of the word "standard" above; I can discern
  at least three usages of the word.  The first is "standard" as in
  what people think an RFC is, and the second usage is the
  specific "standards track" that the RFC is on, and the third
  usage is "standard" as a synonym for quality.  Maybe re-writing
  the above to better outline the intent may not be a bad idea.
  Something like the following (please feel free to edit):

      Moving documents or RFCs along the standards track can be
      an important signal to the user and implementor communities,
      and the process of revising a RFC on the standards track
      for further advancement can help improve the quality of
      implementations that participate.

2) S1, third paragraph:
  s/This memo may help in/This memo helps in/

3) S1, page four, fifth line:
  s/problem features/features that proved to be problematic/

4) S2, page five, first "Note":
  s/many more implementations or the/many more implementations, or the/

5) In S2, page five, second "Note":
  s/In contrast,/By contrast,/

6) S5.1:
  s/test-lab results/results derived from laboratory testing/

7) S5.3:
  s/implemented and syntax/implemented and their syntax/

8) S5.4, second line:
  s/implementation, the result/implementation; the result/