Subject: [Gen-art] Gen-ART review of draft-ietf-ospf-mt-06.txt

From: Miguel Garcia <[email-masked]>
Date: Wed, 01 Nov 2006 09:31:48 +0200

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-masked]>
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-masked]>

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 01 Nov 2006 10:26:01 +0200

Just restricting to the point that requires further discussion:

Padma Pillay-Esnault wrote:
> Miguel Garcia wrote:

>> - 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.
> 

Take for example the figure located in Section 4.1. I am suggestion to 
add a caption, so I can see that this is "Figure 1" (and not Figure 3), 
and there is a title for such figure. Assuming that Figure 1 represents 
the OSPF Options field, then you could write:

            +---+---+---+---+---+---+---+---+
            |DN |O  |DC |EA |NP |MC |E  |MT |
            +---+---+---+---+---+---+---+---+

            Figure 1: The OSPF Options field

Also, you should capitalize "Options" in the text, as it is done in RFC 
2328.

BR,

      Miguel

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Tue, 31 Oct 2006 23:50:06 -0800

> create some registry, and fill it with some values, but it is not 
We will modify this portion we do not want IANA management of the MT space.

> 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.

> I also have a doubt about the normative "MUST" that appears in the 
> first paragraph of Section 3.6, which reads:
>
Agree this can be removed as well.

> - Expand the first occurrence of every acronym, e.g., OSPF, TOS, etc.
ok

> - Section 3.3: add an informative reference to RFC 2328.
ok

> recommend to turn the first paragraph in Section 3.6 to present tense.
ok

> s/[128-255]/ranging 128 to 255
ok

> - Section 4.1, last paragraph: s/enable/enabled
ok

>    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 
ok

> [RFC1583]. There should be a consistent reference scheme.
ok

Thanks for your review

Padma

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 01 Nov 2006 07:28:33 -0800

Miguel

Miguel Garcia wrote:

>>> nice to refer to figures (even from other drafts). I would suggest 
>>> to add captions to all the figures.
>>>
> add a caption, so I can see that this is "Figure 1" (and not Figure 
> 3), and there is a title for such figure. Assuming that Figure 1 
> represents the OSPF Options field, then you could write:
>
> Also, you should capitalize "Options" in the text, as it is done in 
> RFC 2328.
>

OK.

Thanks!

Padma