Subject: [Gen-art] Gen-ART LC review of draft-ietf-ccamp-gmpls-ason-routing-ospf-07

From: Ben Campbell <[email-masked]>
Date: Thu, 12 Mar 2009 15:38:45 -0500

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-ccamp-gmpls-ason-routing-ospf-07
Reviewer: Ben Campbell
Review Date: 2009-03-12
IETF LC End Date: 2009-03-13
IESG Telechat date: (if known)

Summary:

This draft is very close to ready for publication as an experimental  
RFC. I found one minor issue with the IANA considerations that should  
be fixed first. I also have a few comments related to editorial issues  
and nits.

Major issues:

None

Minor issues:

-- Section 9.1:

This section shows the sub-TLV types as TBD, but at least some of the  
references sections specify type numbers.

Nits/editorial comments:

-- general:

It would be helpful to have referenceable numbers for the TLV format  
figures.

Using non-mnemonic citations as if they were nouns in a sentence  
creates extra work for the reader, who must flip back to the  
references to understand the sentence.  That is, the form  "...defined  
in [xxx]".  It's better to say "defined in foo [xxx]". It's not as bad  
with mnemonic citations (e.g. "defined in [foo]"), but it can still  
cause confusion if text is quoted in other documents without the  
associated reference section.

-- section 2, 2nd paragraph: "The
    limit of the subdivision results is an RA that contains just two
    sub-networks interconnected by a single link."

I don't follow the last sentence. Is it possible "results is" was  
meant to be "results in"?

-- section 3.1, last paragraph, first sentence: "The local addresses  
that can be learned from Opaque TE LSAs."

incomplete sentence. Is "that" spurious?

section 3.2, first paragraph after the figure: "Length is set to Sum[n] 
[4 + #32-bit words/4] where n is the
        number of local prefixes included in the sub-TLV."

I'm not sure I understand the expression.

-- section 4.1, 3rd paragraph:

Please expand LSC and PSC on first use.

-- section 6, 3rd paragraph:

s/informtation/information

-- idnits reports the following:

>   == You're using the IETF Trust Provisions Section 6.b License  
> Notice from
>      10 Nov 2008 rather than the newer Notice from 12 Feb 2009.   
> Both versions
>      are accepted up to the end of March 2009; after that you'll  
> need to use
>      the 12 Feb 2009 Notice.  (See http://trustee.ietf.org/license-info/)
>
>   == The document seems to lack a disclaimer for pre-RFC5378 work,  
> but was
>      first submitted before 10 November 2008.  Should you add the  
> disclaimer?
>      (See the Legal Provisions document at
>      http://trustee.ietf.org/license-info for more information.).
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Mar 2009 13:07:04 -0000

Hi Ben,

Thanks for your review.

Dimitri, need your help!
See in line below.

Adrian

> references sections specify type numbers.

OK, I found section 9.1
|   Value        Sub-TLV                                       Reference
|   -----------  --------------------------------------------  ----------
|   TBD          Local TE Router ID                            [This.ID]

But, in section 5.3
| The Type of the Local TE Router-ID sub-TLV is 5

Similarly,
|   TBD          Local and Remote TE Router ID                 [This.ID]

But, section 5.2
|    The Type of the Local and Remote TE Router-ID sub-TLV is 17

Also,
|   TBD          Node IPv4 Local Prefix                        [This.ID]
|   TBD          Node IPv6 Local Prefix                        [This.ID]

But in section 3
|  - Node IPv4 Local Prefix sub-TLV: Type 3 - Length: variable
|  - Node IPv6 Local Prefix sub-TLV: Type 4 - Length: variable

Dimitri, are these values:
- required
- desired
- suggested?

> It would be helpful to have referenceable numbers for the TLV format 

Yeah, might be nice, but since the figures are not referenced outside the 
section in which they appear, I think we won't bother this time.

> Using non-mnemonic citations as if they were nouns in a sentence  creates 
> extra work for the reader, who must flip back to the  references to 
> understand the sentence.  That is, the form  "...defined  in [xxx]".  It's 
> better to say "defined in foo [xxx]". It's not as bad  with mnemonic 
> citations (e.g. "defined in [foo]"), but it can still  cause confusion if 
> text is quoted in other documents without the  associated reference 
> section.

Hmmm.
This notation seems to be used pretty widely.
I'd hate to see text that said "..defined in RFC 1234 [RFC1234]." :-)

> I don't follow the last sentence. Is it possible "results is" was  meant 
> to be "results in"?

Yes. Thanks.

> -- section 3.1, last paragraph, first sentence: "The local addresses  that 
> can be learned from Opaque TE LSAs."
>

Good catch.
OLD
   The local addresses that can be learned from Opaque TE LSAs. That is,
   router address and TE interface addresses SHOULD NOT be advertised
   in the node IPv4 local prefix sub-TLV.
NEW
   The local addresses that can be learned from Opaque TE LSAs (that is,
   the router address and TE interface addresses) SHOULD NOT be
   advertised in the node IPv4 local prefix sub-TLV.

> section 3.2, first paragraph after the figure: "Length is set to Sum[n] [4 
> + #32-bit words/4] where n is the

But you think you might? :-)

Hard doing scientific notation in ASCII, isn't it?
OLD
     Length is set to Sum[n][4 + #32-bit words/4] where n is the
       number of local prefixes included in the sub-TLV. The encoding of
       each prefix potentially using fewer than four 32-bit words is
       described below.
NEW
     Length is set to the sum over all of the local prefixes included in
       the sub-TLV of (4 + (number of 32-bit words in the prefix)/4 ).
       The encoding of each prefix potentially using fewer than four
       32-bit words is described below.

> Please expand LSC and PSC on first use.

oke

> s/informtation/information

oke

> -- idnits reports the following:

Who can keep up with the IPR change rate?
All IPR notices correct at time of submission.
No doubt they will be updated and correct many times in the next weeks.

Many thanks,
Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 13 Mar 2009 14:19:39 +0100

Adrian: 

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Friday, March 13, 2009 2:07 PM
> To: Ben Campbell; PAPADIMITRIOU Dimitri; General Area Review Team
> Cc: [email-masked]; [email-masked]
> Subject: Re: Gen-ART LC review of 
> draft-ietf-ccamp-gmpls-ason-routing-ospf-07
> 
> Hi Ben,
> 
> Thanks for your review.
> 
> Dimitri, need your help!
> See in line below.
> 
> Adrian
> 
> > Minor issues:
> >
> > -- Section 9.1:
> >
> |   Value        Sub-TLV                                      
>  Reference

The former.

> section in which they appear, I think we won't bother this time.

usually we ref. the sub-section itself.

> I'd hate to see text that said "..defined in RFC 1234 [RFC1234]." :-)

it is correct but as most IETF refs. are RFCs it reads often like Adrian
states.

>        32-bit words is described below.

correct.

> No doubt they will be updated and correct many times in the 

is there something specific here to be done from my side ?

much thanks,
-dimitri.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Mar 2009 13:52:36 -0500

Thanks for the quick response!

See inline. I cut out sections that did not appear to need a further  
response from me.

On Mar 13, 2009, at 8:07 AM, Adrian Farrel wrote:

[...]

>> It would be helpful to have referenceable numbers for the TLV  
>> format figures.
>
> Yeah, might be nice, but since the figures are not referenced  
> outside the section in which they appear, I think we won't bother  
> this time.
>

Okay, not a biggie.

>> references to understand the sentence.  That is, the form   
>> "...defined  in [xxx]".  It's better to say "defined in foo [xxx]".  
>> It's not as bad  with mnemonic citations (e.g. "defined in [foo]"),  
>> but it can still  cause confusion if text is quoted in other  
>> documents without the  associated reference section.
>
> Hmmm.

For the IETF community, an RFC number pretty much counts as a mnemonic  
reference, since that's the way we talk about the documents. This  
draft has some ITU references that are not mnemonic to me, but may be  
to others.

In any case, please consider the citation comment as a suggestion for  
future reference. I will not object further if the authors choose to  
not to act on it.

[...]

>> section 3.2, first paragraph after the figure: "Length is set to  
>> Sum[n] [4 + #32-bit words/4] where n is the

That helps. Actually, the addition of "... words in the prefix"  
probably helps more than anything.

(I was thinking there might be a simpler expression, but on re-reading  
I assume that the number of words per per prefix may vary across  
prefix instances in a given instance of the sub-TLV, right?)

> No doubt they will be updated and correct many times in the next  

Hey, I'm just reporting what the tool said ;-) Hopefully things have  
settled out there a bit. If we're lucky.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Mar 2009 13:54:18 -0500

For the record, this email along with Adrian's address all of my  
comments.

Thanks!

Ben.

On Mar 13, 2009, at 8:19 AM, PAPADIMITRIOU Dimitri wrote:

>> outside the