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
