[Gen-art] Gen-ART review of draft-ietf-iporpr-basic-03.txt

[Miguel Garcia <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-iporpr-basic-03.txt
Reviewer: Miguel Garcia <[e-mail]>
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/


Regards,

          Miguel Garcia
-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art