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
>
>
>
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
