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

[Daniele Ceccarelli <[e-mail]>]

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:[e-mail]]
> Sent: martedì 18 ottobre 2016 08:23
> To: Yemin (Amy) <[e-mail]>
> Cc: [e-mail]; draft-ietf-ccamp-ospf-availability-
> [e-mail]
> Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-
> 07
> 
> 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.
> > >
> > > __________________________________________