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
