Hi all, After discussing with Jouni, authors, chairs, Lou and our AD, we will update the draft with the following changes to clarify Jouni's concern:
In the Abstract and Introduction, add: "It is intended that technology-specific documents will reference this document to describe specific uses." Section 3.2 is updated as the following: "A node advertising an interface with a Switching Capability which supports variable bandwidth attached SHOULD contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA messages. Each ISCD Availability sub-TLV provides the information about how much bandwidth a link can support for a specified availability. This information MAY be used for path calculation by the node(s). The ISCD Availability sub-TLV MUST NOT be sent in ISCDs with Switching Capability field values that have not been defined to support the ISCD Availability sub-TLV. Non-supporting nodes would see such as a malformed ISCD/LSA. Absence of the ISCD Availability sub-TLV in an ISCD containing Switching Capability field values that have been defined to support the ISCD Availability sub-TLV, SHALL be interpreted as representing fixed-bandwidth link with the highest availability value. Only one ISCD Availability sub-TLVs for the specific availability level SHOULD be sent. If multiple are present, only the first ISCD Availability sub-TLV for an availability level carried in the same ISCD SHALL be processed." In the IANA considerations, add: "Technology-specific documents will reference this document to describe specific use of this Availability sub-TLV." The draft will be revised by a new version. BR, Amy -----Original Message----- From: jouni.nospam [mailto:[email protected]] Sent: Wednesday, October 19, 2016 5:26 AM To: Daniele Ceccarelli Cc: Yemin (Amy); [email protected]; [email protected] Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07 Hi Daniele, > On Oct 17, 2016, at 11:28 PM, Daniele Ceccarelli > <[email protected]> wrote: > > Hi Jouni, > > Thanks a lot for your review and your thoughts. I tend to agree with you, > publishing a document referencing a future one doesn't make much sense. > We had a long discussion inside the WG on how to progress this draft with > many alternative options and this one happened to be the less painful one. > > What I would suggest to do is to ask Amy to publish that document ASAP, > reference it and then progress the two drafts as a cluster (i.e. this one > needs to wait for the other one to become an RFC). > Would this work for you? Deborah, Fatai, what's your opinion? I assume “that document” above refers to a new draft that would amend RFC4203 to handle generic TLVs in scsi field. If this is the case it would be a preferable outcome to me. I know having a normative reference in draft-ietf-ccamp-ospf-availability-extension to a new work is a bit of pain but I guess there’s no harm as you were already fine publishing an extension without describing how to implement it in the first place. - Jouni > > BR > Daniele > >> -----Original Message----- >> From: jouni.nospam [mailto:[email protected]] >> Sent: martedì 18 ottobre 2016 08:23 >> To: Yemin (Amy) <[email protected]> >> Cc: [email protected]; draft-ietf-ccamp-ospf-availability- >> [email protected] >> Subject: Re: Gen-ATR review of >> draft-ietf-ccamp-ospf-availability-extension- >> 07 >> >> Hi, >> >>> On Oct 17, 2016, at 8:16 PM, Yemin (Amy) <[email protected]> >> wrote: >>> >>> Hi Jouni, >>> >>> You're right that the current draft text doesn't provide any >>> information >> about the discussion. >>> So how about add the following text at the end of section 3.1: >>> This document only defines the Availability TLV, how the existing >>> Switching >> Capability makes use of the Availability TLV will be addressed in a >> different document. An example is to define a new type code for the >> Availability TLV, if the Switching Capability-specific information (SCSI) >> supports TLV format. >> >> With some rewording I could be OK.. I am not going to be stubborn >> trying to block this document. Just add that the “different document” >> is “different future document” or something like that. >> >> Anyway, I am still somewhat surprised there is now a document (this >> draft under review) defining a new extension to RFC4203 before there >> is a document that actually describes how to do that in a proper way, >> specifically if this draft does not want to do that. The order is imho >> wrong.. just saying.. >> >> - Jouni >> >> >> >> >>> >>> Section 3 of RFC7688 provides clear definition for new SC and SCSI. >>> But >> since the conclusion is to use another different document, other than >> this document to explain the technology specific usage(including the >> SC/SCSI allocation), it’s preferred not to include the such text in this >> document. >>> >>> BR, >>> Amy >>> -----Original Message----- >>> From: jouni.nospam [mailto:[email protected]] >>> Sent: Monday, October 17, 2016 11:21 PM >>> To: Yemin (Amy) >>> Cc: [email protected]; >>> [email protected] >>> Subject: Re: Gen-ATR review of >>> draft-ietf-ccamp-ospf-availability-extension-07 >>> >>> Hi, >>> >>> >>>> On Oct 17, 2016, at 1:06 AM, Yemin (Amy) <[email protected]> >> wrote: >>>> >>>> Hi Jouni, >>>> >>>> Thanks very much for the comments. I fixed the nits in the draft. >>>> >>>> Regarding the Switching Capability-specific information field, we >>>> had the >> discussion in WG, and here's the summary/conclusion: >>>> It's decided that this document will just define the availability >>>> TLV, and a >> new draft will define its technology specific usage. >>> >>> Ok, thanks for sharing this. This document had no mention or >>> guidance of >> this kind of decision. I would have assumed some text since the >> extension defined in this document is seemingly backwards >> incompatible without some glue. As the text is now, is not sufficient. >>> >>> I would appreciate text along lines that can be found in Section 3 >>> of >> RFC7688 with an addition of the details you point out below regarding >> the allocation of new Switching-capability types. Also, it would not >> hurt describing (with the Switching-capability types text) how the >> situation where an existing non-TLV Switching Capability-specific >> information and the new TLV-based information have to coexist.. or >> whether that kind format is not supported. >>> >>> - Jouni >>> >>> >>>> For example, for the SCSI which supports TLV(e.g., OTN/WSON), a new >> type code is needed to make use of availability TLV. >>>> For the SCSI who doesn’t support TLV(e.g., PSC), a new SC types is >> needed. >>>> >>>> BR, >>>> Amy >>>> >>>> -----Original Message----- >>>> From: jouni.nospam [mailto:[email protected]] >>>> Sent: Monday, October 17, 2016 5:50 AM >>>> To: [email protected] >>>> Cc: [email protected] >>>> Subject: Gen-ATR review of >>>> draft-ietf-ccamp-ospf-availability-extension-07 >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed by >> the IESG for the IETF Chair. Please treat these comments just like >> any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> >>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-ccamp-ospf-availability-extension-07 >>>> Reviewer: Jouni Korhonen >>>> Review Date: 2016-10-16 >>>> IETF LC End Date: 2016-10-24 >>>> IESG Telechat date: 2016-11-03 >>>> >>>> Summary: >>>> >>>> Document is ready with nits. >>>> >>>> Major issues: >>>> >>>> None. >>>> >>>> Minor issues: >>>> >>>> It is not clear to me how the ISCD Availability sub-TLV is encoded >>>> into RFC4203 Switching Capability-specific information field. This >>>> is because RFC4203 lists specific encodings depending on “Switching Cap” >>>> field and those encoded information fields seem not to be TLVs. I >>>> would like to see some text that deals with switching cap, its >>>> relation to the TLV described in this document and the coexistence >>>> with existing capability specific information fields described in >>>> RFC4203. If I did not understand something regarding the encoding >>>> that is supposed to be trivial I am happy to told that ;) >>>> >>>> Nits/editorial comments: >>>> >>>> o Line 21: ISCD is not expanded. >>>> o Line 142: unnecessary extra space in "a < availability”. >>>> o Line 150: Space needed before the reference "protocol[ETPAI].” >>>> o Line 142-.. TE is never expanded or part of the list acronyms. >>>> o Lines 176-178: formatting issue with indentation, line spacing >>>> and line endings (not a fullstop but ‘;’). >>>> o Line 162: TLV is never expanded or part of the list acronyms. >>>> >>>> __________________________________________ > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
