> 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: gen-art@ietf.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

Reply via email to