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 <[EMAIL PROTECTED]>
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:+358-50-4804586
sip:[EMAIL PROTECTED]
Nokia Research Center Helsinki, Finland
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
