Document: draft-ietf-ospf-mt-06.txt Reviewer: Miguel Garcia Review Date: 2006-11-01 IETF LC Date: 2006-11-02 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.