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? BR Daniele > -----Original Message----- > From: jouni.nospam [mailto:jouni.nos...@gmail.com] > Sent: martedì 18 ottobre 2016 08:23 > To: Yemin (Amy) <amy.ye...@huawei.com> > Cc: firstname.lastname@example.org; draft-ietf-ccamp-ospf-availability- > extension....@ietf.org > Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension- > 07 > > Hi, > > > On Oct 17, 2016, at 8:16 PM, Yemin (Amy) <amy.ye...@huawei.com> > 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:jouni.nos...@gmail.com] > > Sent: Monday, October 17, 2016 11:21 PM > > To: Yemin (Amy) > > Cc: email@example.com; > > draft-ietf-ccamp-ospf-availability-extension....@ietf.org > > Subject: Re: Gen-ATR review of > > draft-ietf-ccamp-ospf-availability-extension-07 > > > > Hi, > > > > > > > On Oct 17, 2016, at 1:06 AM, Yemin (Amy) <amy.ye...@huawei.com> > 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:jouni.nos...@gmail.com] > > > Sent: Monday, October 17, 2016 5:50 AM > > > To: firstname.lastname@example.org > > > Cc: draft-ietf-ccamp-ospf-availability-extension....@ietf.org > > > 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 Genemail@example.com https://www.ietf.org/mailman/listinfo/gen-art