> 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..
> 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.
> -----Original Message-----
> From: jouni.nospam [mailto:jouni.nos...@gmail.com]
> Sent: Monday, October 17, 2016 11:21 PM
> To: Yemin (Amy)
> Cc: firstname.lastname@example.org;
> Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07
> > 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: email@example.com
> > 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