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

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

Hi Daniele,


> On Oct 17, 2016, at 11:28 PM, Daniele Ceccarelli <[e-mail]> wrote:
> 
> 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?


I assume “that document” above refers to a new draft that would amend RFC4203 to handle generic TLVs in scsi field. If this is the case it would be a preferable outcome to me.

I know having a normative reference in draft-ietf-ccamp-ospf-availability-extension to a new work is a bit of pain but I guess there’s no harm as you were already fine publishing an extension without describing how to implement it in the first place.

- Jouni


> 
> 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.
>>>> 
>>>> __________________________________________
>