Adrian and Dimitri, The submitted -12 version looks good - I saw one minor nit:
- Second line of 5.1.5: "Attributes Flags" -> "Call Attributes Flags" Thanks for clarifying the distinction between the (renamed) Call Attributes Flags TLV vs. the Attributes Flags TLV - it's now clear what's going on, and the revised requests to IANA should also be clear. On Adrian's other comments: >>> 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. This is only about combining the text diagram, not combining the definitions. If/when the definitions diverge, revised ASCII text diagrams for one or both sub-TLV formats can be included in the document that diverges the definitions. The definitions are distinct in -12, they just point to the same ASCII text diagram. >>> 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. Dimitri did something even better in -12; he documented the Type and Length in the descriptions below the ASCII figures and included the values in the descriptions. Given this, the actual values for Type and Length do not need to be inserted into the ASCII figures. >>> 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. I think such a diagram would help implementers, and would force any future modifications to consider the effects on both objects, which I think is beneficial. As noted in the review, this was a minor comment, so removal of the diagram from -12 would be ok with me. Thanks, --David > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Lou Berger > Sent: Sunday, February 21, 2010 7:37 AM > To: Adrian Farrel > Cc: [email protected]; [email protected]; draft-ietf-ccamp-gmpls-mln- > [email protected]; Black, David; PAPADIMITRIOU Dimitri > Subject: Re: [Gen-art] 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-gm pls-mln-extensions- > 11.txt&url2=http://www.ietf.org/staging/draft-ietf-ccamp-gmpls-mln-exten sions-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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
