Re: [Gen-art] Next steps with draft-ietf-ccamp-gmpls-mln-extensions

[Adrian Farrel <[e-mail]>]

Ah thanks, I had only checked the datatracker. I guess this will pop out on 
Monday when the Secretariat get to work.

It seems to address the points.

Thanks.

Adrian
----- Original Message ----- 
From: "Lou Berger" <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
Cc: "PAPADIMITRIOU Dimitri" <[e-mail]>; 
<[e-mail]>; 
<[e-mail]>; 
<[e-mail]>; <[e-mail]>
Sent: Sunday, February 21, 2010 12:37 PM
Subject: Re: Next steps with draft-ietf-ccamp-gmpls-mln-extensions


> Adrian,
> It looks like Dimitri is one step ahead (at least for now ;-)  Take a
> look at:
>
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-gmpls-mln-extensions-11.txt&url2=http://www.ietf.org/staging/draft-ietf-ccamp-gmpls-mln-extensions-12.txt
>
> I suspect all issues are addressed in this rev.  Once you and David
> confirm, we can respond to IANA with the requisite changes.
>
> Please confirm that there are/are not remaining open issues.
>
> Much thanks,
>
> Lou
>
> On 2/21/2010 6:28 AM, Adrian Farrel wrote:
>> Hi Dimitri,
>>
>> Looking at your response to David Black's review, I think an update to 
>> the
>> draft is needed. I'd like to get it onto an IESG agenda before Anaheim as 
>> it
>> has several Ethernet drafts backed up behind it.
>>
>>>> Sections 5.1.4, 5.2.1 and 8 have me confused about the
>>>> Attributes Flags TLV:
>>>> - Section 5.1.4 defines an Attributes Flags TLV here
>>>
>>> for Virtual TE links: the CALL ATTRIBUTE is defined in this document
>>>
>>>> - Section 5.2.1 points to RFC 5420 for what's apparently a different
>>>>   Attributes Flags TLV and defines a Pre-Planned LSP flag in
>>>> that TLV.
>>>
>>> for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to
>>> introduced a new flag
>>>
>>>> - Section 8 then apparently instructs IANA to put that bit into the
>>>>   Attributes Flags TLV defined in Section 5.1.4 .
>>>>   Something appears to be wrong with this combination - what was
>>>>   the intent?  If these two TLVs are the same, or share a common bit
>>>>   assignment registry, that should be stated.
>>>
>>> I will clarify this because as they both refer to "attributes" precision
>>> of the terms
>>> used is indeed critical
>>
>> I think David is quite right that there is confusion. My understanding is 
>> as
>> follows...
>>
>> There are two separate objects: the Call_Attribute object and the
>> LSP_Attribute object.
>>
>> Both of these objects can carry a TLV called the "Attributes Flags TLV". 
>> But
>> this is a DIFFERENT TLV for the two objects. In the first case, it is for
>> use in the Call_Attribute object and is defined in this document. In the
>> second case it is for use on the LSP_Attribute object and is defined in 
>> RFC
>> 4020 with this document only defining a new flag.
>>
>> My suggestion to make this crystal clear is to change the name of the
>> Attributes Flags TLV carried in the Call_Attribute object to be the "Call
>> Attibutes Flags TLV". I think this is a really easy search and replace, 
>> and
>> fixes this issue.
>>
>> David also said...
>>
>>>> The IACD sub-TLV formats for OSPF and IS-IS appear to be
>>>> identical.  If they are in fact identical, a single ASCII text diagram
>>>> should be used for both.
>>
>> They are identical, but that is only good fortune. There is no 
>> requirement
>> that they be the same, and there is no required mapping between the two.
>> Furthermore, a future revision might need to change the format or content
>> for one protocol, but not for the other, etc. Thus, we prefer to keep the
>> definitions distinct.
>>
>>>> The description of the IACD sub-TLV format does not describe the
>>>> Max LSP Bandwidth fields.  At a minimum the units and/or encoding of
>>>> these fields should be described here, even thought the full
>>>> specification may be elsewhere.
>>
>> David is correct that the fields should be mentioned, but I think it 
>> would
>> be OK to include a reference to RFC4203 and RFC5307.
>>
>>>> Please add the values for Type and Length for the XRO SC
>>>> subobject into the ASCII figure in Section 4.1.1 .
>>
>> The convention in RSVP-TE is to not include the Type and Length (most
>> relevantly, see RFC 4874). It would be inappropriate to change that
>> convention here.
>>
>>>> Section 4.1.2 defines a new subobject by making minor changes to an
>>>> existing one in another RFC; a complete ASCII diagram of the new
>>>> subobject would be helpful - please add one.
>>
>> There is absolutely no change in the format of the subobject. The only
>> difference is the interpretation of the L bit. In order to keep the
>> subobjects in lock-step, it is preferable to not include a further ASCII
>> diagram.
>>
>>>> idnits 2.12.00 found three nits:
>>>>
>>>>   == The page length should not exceed 58 lines per page, but
>>>>         there was 1 longer page, the longest (page 1) being 62 lines
>>
>> This is the first page caused by leading several CRLF
>>
>>>>   ** There are 144 instances of too long lines in the
>>>>        document, the longest one being 1 character in
>>>>        excess of 72.
>>
>> Seems to be a product of MS Word.
>> I think the whole thing needs to be left-shifted by 7 spaces.
>>
>>>>   == Line 781 has weird spacing: '...ndwidth  is st...'
>>
>> Yup. Section 5.2.2 para 2 has a double space.
>>
>> Finally, could you or Lou please confirm the IANA actions in the email 
>> from
>> Amanda on the 16th.
>>
>> Many thanks,
>> Adrian
>>
>>
>>
>>
>