Miguel Garcia wrote:
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.
We will modify this portion we do not want IANA management of the MT space.
- 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.
<excerpt>
If links need to be removed from the default topology, an MT capable
router MUST be
configured in DefaultExclusionCapability mode.
<excerpt>
What we mean is:
By default the DefaultExclusionCapabilityMode is off. If you need to
exclude links from the default topology
then you must turn the DefaultExclusionCapabilityMode on by configuration.
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.
Agree this can be removed as well.
Nits:
- Expand the first occurrence of every acronym, e.g., OSPF, TOS, etc.
ok
- Section 3.3: add an informative reference to RFC 2328.
ok
- 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.
ok
- 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
ok
- 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.
Can you be more explicit here.
- Section 4.1, last paragraph: s/enable/enabled
ok
- 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.
ok
- 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.
ok
- 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.
ok
Thanks for your review
Padma
Regards,
Miguel Garcia <[EMAIL PROTECTED]>
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
