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

[Ben Campbell <[e-mail]>]

For the record, this version addresses all of my comments.

Thanks!

Ben.

On Apr 7, 2009, at 5:34 PM, Adrian Farrel wrote:

> Hi Ben,
>
> New revision just out fixes the issues.
>
> Thanks again.
> Adrian
> ----- Original Message ----- From: "Ben Campbell" <[e-mail]>
> To: "PAPADIMITRIOU Dimitri" <[e-mail]>
> Cc: "Adrian Farrel" <[e-mail]>; "General Area Review  
> Team" <[e-mail]>; <[e-mail]>; <[e-mail]>
> Sent: Tuesday, March 17, 2009 7:54 PM
> Subject: Re: Gen-ART LC review of draft-ietf-ccamp-gmpls-ason- 
> routing-ospf-07
>
>
>> 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
>>>>
>>>>
>>
>