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-ospf-mt-06.txt
Reviewer: Miguel Garcia <[EMAIL PROTECTED]>
Review Date: 2006-11-01
IETF LC Date: 2006-11-02
IESG Telechat date: not known
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Comments:
The draft has two important issues that should be clarified, and a
number of nits. In order of importance:
- IANA Considerations section. In this section the draft explains what
the draft does, but not what IANA has to do. It does not provide any
instruction to IANA. Most likely IANA has to do something, operate or
create some registry, and fill it with some values, but it is not explained.
- Normative text in configuration: The second paragraph of Section 5 reads:
"... an MT capable router MUST be
configured in DefaultExclusionCapability mode."
I failed to understand how to implement and test a normative MUST in a
configuration issue. I don't see how this affects the implementation.
In my opinion, the above "MUST" is not a "MUST", but perhaps an
explanatory text that provides guidelines to the human being that
configures an MT capable router in a non-normative way.
I also have a doubt about the normative "MUST" that appears in the first
paragraph of Section 3.6, which reads:
"Each nexthop computed during
the MT SPF MUST belong to the same MT."
If I understand correctly, a router is computing some received
information, so how can it make sure that each MT SPF belongs to the
same MT in a received data? This smells like another un-implementable MUST.
Nits:
- Expand the first occurrence of every acronym, e.g., OSPF, TOS, etc.
- Section 3.3: add an informative reference to RFC 2328.
- Text is easier to read if the future tense is not used. I would
recommend to turn the first paragraph in Section 3.6 to present tense.
- Section 3.7: the usage of brackets to indicate value ranges can
mislead the reader with references, which they aren't. I would suggest
to use some other type of brackets for value ranges or explain the
contents, e.g.:
s/[0-127]/from 0 to 127
s/[128-255]/ranging 128 to 255
- None of the figures in the draft include a caption. Captions are nice
to refer to figures (even from other drafts). I would suggest to add
captions to all the figures.
- Section 4.1, last paragraph: s/enable/enabled
- Section 4.2, last paragraph. It is hard to parse this sentence. I
think an important comma is missing. Suggestion:
OLD:
When an area data structure is created the
DefaultExclusionCapability is disabled by default.
NEW:
When an area data structure is created, the
^^^
DefaultExclusionCapability is disabled by default.
- Section 5.1. The hellos and hello are hard to parse without quoting or
capitalization. RFC 1793 refers to them as Hellos and Hello Packet
(notice the capitalization), so I would suggest to capitalize them as
well for better understanding.
- The way of making references is not consistent. Sometimes they are
used by name, such as [OSPF], some other times by RFC, such as
[RFC1583]. There should be a consistent reference scheme.
Regards,
Miguel Garcia <[EMAIL PROTECTED]>
--
Miguel A. Garcia tel:+358-50-4804586
sip:[EMAIL PROTECTED]
Nokia Research Center Helsinki, Finland
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
