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

[Ben Campbell <[e-mail]>]

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:

> Adrian:
>
>> -----Original Message-----
>> From: Adrian Farrel [mailto:[e-mail]]
>> Sent: Friday, March 13, 2009 2:07 PM
>> To: Ben Campbell; PAPADIMITRIOU Dimitri; General Area Review Team
>> Cc: [e-mail]; [e-mail]
>> 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:
>>>
>>> This section shows the sub-TLV types as TBD, but at least
>> some of the
>>> 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?
>
> The former.
>
>>> Nits/editorial comments:
>>>
>>> -- general:
>>>
>>> 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.
>
> usually we ref. the sub-section itself.
>
>>> 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]." :-)
>
> it is correct but as most IETF refs. are RFCs it reads often like  
> Adrian
> states.
>
>>> -- 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"?
>>
>> Yes. Thanks.
>>
>>> -- section 3.1, last paragraph, first sentence: "The local 
>> addresses  that
>>> can be learned from Opaque TE LSAs."
>>>
>>> incomplete sentence. Is "that" spurious?
>>
>> 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
>>>       number of local prefixes included in the sub-TLV."
>>>
>>> I'm not sure I understand the expression.
>>
>> 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.
>
> correct.
>
>>> -- section 4.1, 3rd paragraph:
>>>
>>> Please expand LSC and PSC on first use.
>>
>> oke
>>
>>> -- section 6, 3rd paragraph:
>>>
>>> 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.
>
> is there something specific here to be done from my side ?
>
> much thanks,
> -dimitri.
>> Many thanks,
>> Adrian
>>
>>