Document: draft-ietf-iporpr-basic-03.txt Reviewer: Miguel Garcia Review Date: 2006-11-13 IETF LC End Date: 2006-11-16 IESG Telechat date: 2006-11-16 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: - Section 2 contains normative statements that are applicable to the reader of the spec, e.g. "This section SHALL NOT be used as a definitive description ..." and "IEEE 802.17 SHALL be consulted ..." However, none of them can be considered normative according to RFC 2119. I propose to wording around the following lines: "It is not the purpose of this section to become a replacement of the normative IEEE 802.17 [2] or IEEE 802.17a [14] specifications." and "The reader is encouraged to consult IEEE 802.17 [2] and IEEE 802.17a [14] for normative details of functionality." - Section 3.3, last sentence of the section, contains some unclear wording around the normative MAY. The text reads: "Note that a maximum jumbo frame payload size that MAY be supported is defined at 9100 bytes." I don't know how to digest the MAY. I don't understand if it is a normative MAY of this specification or of the 802.17 spec, as I suspect. Perhaps the text wants to say: "Note that 802.17 can optional support jumbo frame payloads, in which case the maximum size is 9100 bytes." - Section 8, IANA Considerations. In the sake of clarity, I would suggest to reword the text as following: "IANA is instructed to allocate a new hardware type (hrd) for IEEE 802.17 in the Address Resolution Protocol Parameters registry, as follows: Number Hardware Type (hrd) References ------ ----------------------------------- ---------- [xx] IEEE 802.17 [RFC YYYY] Note to the RFC Editor: Replace [xx] with the assigned value and [RFC YYYY] with the RFC number of this specification." - I will advocate to delete Section 4.1.1. Starting with, the title is weird in a specification. The first paragraph does not fit here at all, because it has to be expanded in the IANA Considerations Section. The second paragraph provides some historical background, which once the document is published as an RFC, becomes irrelevant. So I suggest to delete the whole section 4.1.1. - References should be split in Normative and Informative Nits: - Expand the first occurrence of every acronym, e.g., MPLS, IEEE, TTL, MAC, etc. - Include a Table of Contents - Avoid use of unnecessary future tense terms. For example, in Section 1, the draft says: "This document will describe all the necessary mappings to aid interoperable networks. " and should be written in present tense, e.g., "this document describes ..." - Starting at Section 2.2.1, the draft uses square brackets to indicate protocol fields. These can be confused with references, which use also square brackets, so you may consider the use of some other symbol to denote protocol fields (example: ', ", -, (), etc.). So, the first line in Section 2.2.1 could be written as: The destination address (DA) (destination-address) is the ... Also, I noticed that in other sections, such as 2.2.4, the protocol fields are enclosed in parenthesis (see last line of the first paragraph in Section 2.2.4), so both should use the same mechanism. - Section 2.2.3, 2nd line: s/is it ability/is its ability - Section 2.2.4, 3rd line: s/parameter indicate a request/parameter indicates a request - Missing final dot in paragraphs in Sections 3.1.4. and 5.5. Also in the 2nd bullet point in Section 7. - Section 4.2, under 3rd paragraph under Table 2. s/These guidleines/These guidelines/