Last Call Review of draft-ietf-tsvwg-iana-ports-
review-ietf-tsvwg-iana-ports-tsvdir-lc-eddy-2011-01-20-00
| Request | Review of | draft-ietf-tsvwg-iana-ports |
|---|---|---|
| Requested rev. | no specific revision (document currently at 10) | |
| Type | Last Call Review | |
| Team | Transport Area Directorate (tsvdir) | |
| Deadline | 2011-02-02 | |
| Requested | 2011-01-19 | |
| Authors | Michelle Cotton, Lars Eggert, Joseph Touch, Magnus Westerlund, Stuart Cheshire | |
| Draft last updated | 2011-01-20 | |
| Completed reviews |
Secdir Last Call review of -?? by Sandra Murphy
Tsvdir Last Call review of -?? by Wesley Eddy |
|
| Assignment | Reviewer | Wesley Eddy |
| State | Completed | |
| Review | review-ietf-tsvwg-iana-ports-tsvdir-lc-eddy-2011-01-20 | |
| Review completed: | 2011-01-20 |
Review
review-ietf-tsvwg-iana-ports-tsvdir-lc-eddy-2011-01-20
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir at ietf.org if you reply to or forward this review. This draft is ready for publication as a BCP RFC. A few small comments which I don't think should be blocking are: 1 - on page 11, in section 6, "near-infinite" is a bit of an exaggeration 2 - on page 16, there's a typo: "MUST accompanied" should be "MUST be accompanied" 3 - on page 17, it may be a good idea to be clear whether the Assignee can be an individual (not just an organization) 4 - on page 17, Contact is defined as a person, but using the IESG as the Contact makes it a group (not a "person"); it might be good to clarify Contact as a person or group of people 5 - on page 17, in the Reference definition, it may be good to qualify the description of broadcast/multicast/anycast use by the protocol as being IP-layer broadcast/multicast/anycast to disambiguate from possible application-layer mechanisms for these that might be used -- Wes Eddy MTI Systems