Re: [Gen-art] Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07

["jouni.nospam" <[e-mail]>]

Hi,

> On Oct 17, 2016, at 8:16 PM, Yemin (Amy) <[e-mail]> 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:[e-mail]] 
> Sent: Monday, October 17, 2016 11:21 PM
> To: Yemin (Amy)
> Cc: [e-mail]; [e-mail]
> Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07
>  
> Hi,
>  
>  
> > On Oct 17, 2016, at 1:06 AM, Yemin (Amy) <[e-mail]> 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:[e-mail]]
> > Sent: Monday, October 17, 2016 5:50 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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.
> > 
> > __________________________________________