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

From: "jouni.nospam" <[email-masked]>
Date: Sun, 16 Oct 2016 14:50:21 -0700

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.

__________________________________________

---

From: "Yemin (Amy)" <[email-masked]>
Date: Mon, 17 Oct 2016 08:06:41 +0000

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.  
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:[email-masked]] 
Sent: Monday, October 17, 2016 5:50 AM
To: [email-masked]
Cc: [email-masked]
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.

Summary:

Major issues:

None.

Minor issues:

Nits/editorial comments:

---

From: "jouni.nospam" <[email-masked]>
Date: Mon, 17 Oct 2016 08:20:50 -0700

Hi,

> On Oct 17, 2016, at 1:06 AM, Yemin (Amy) <[email-masked]> wrote:
> 
> Hi Jouni,
> 

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

---

From: "Yemin (Amy)" <[email-masked]>
Date: Tue, 18 Oct 2016 03:16:52 +0000

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.

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:[email-masked]]
Sent: Monday, October 17, 2016 11:21 PM
To: Yemin (Amy)
Cc: [email-masked]; [email-masked]
Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07

Hi,

> On Oct 17, 2016, at 1:06 AM, Yemin (Amy) <[email-masked]<mailto:[email-masked]>> wrote:

- Jouni

> To: [email-masked]<mailto:[email-masked]>

> Cc: [email-masked]<mailto:[email-masked]>

> Subject: Gen-ATR review of

> draft-ietf-ccamp-ospf-availability-extension-07

> 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 ;)

---

From: "jouni.nospam" <[email-masked]>
Date: Mon, 17 Oct 2016 23:23:25 -0700

Hi,

> On Oct 17, 2016, at 8:16 PM, Yemin (Amy) <[email-masked]> wrote:
> 
> Hi Jouni,
>  

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

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 18 Oct 2016 06:28:26 +0000

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  

> Sent: martedì 18 ottobre 2016 08:23
> To: Yemin (Amy) <[email-masked]>
> > 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
> > Cc: [email-masked];
> > [email-masked]
> > Subject: Re: Gen-ATR review of
> > > 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.
> 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.
> > >
> > > into RFC4203 Switching Capability-specific information field. This
> > > is because RFC4203 lists specific encodings depending on “Switching Cap”
> > > 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 Lines 176-178: formatting issue with indentation, line spacing
> > > and line endings (not a fullstop but ‘;’).

---

From: "jouni.nospam" <[email-masked]>
Date: Tue, 18 Oct 2016 14:26:11 -0700

Hi Daniele,

> On Oct 17, 2016, at 11:28 PM, Daniele Ceccarelli <[email-masked]> wrote:
> 
> Hi Jouni,
> 

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

---

From: "Yemin (Amy)" <[email-masked]>
Date: Mon, 24 Oct 2016 05:16:34 +0000

Hi all,

After discussing with Jouni, authors, chairs, Lou and our AD, we will update the draft with the following changes to clarify Jouni's concern:

In the Abstract and Introduction, add:
"It is intended that technology-specific documents will reference this document to describe specific uses."

Section 3.2 is updated as the following:
"A node advertising an interface with a Switching Capability which supports variable bandwidth attached SHOULD contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA messages. Each ISCD Availability sub-TLV provides the information about how much bandwidth a link can support for a specified availability. This information MAY be used for path calculation by the node(s).

The ISCD Availability sub-TLV MUST NOT be sent in ISCDs with Switching Capability field values that have not been defined to support the ISCD Availability sub-TLV. Non-supporting nodes would see such as a malformed ISCD/LSA.

Absence of the ISCD Availability sub-TLV in an ISCD containing Switching Capability field values that have been defined to support the ISCD Availability sub-TLV, SHALL be interpreted as representing fixed-bandwidth link with the highest availability value. 

Only one ISCD Availability sub-TLVs for the specific availability level SHOULD be sent. If multiple are present, only the first ISCD Availability sub-TLV for an availability level carried in the same ISCD SHALL be processed."

In the IANA considerations, add:
"Technology-specific documents will reference this document to describe specific use of this Availability sub-TLV."

The draft will be revised by a new version. 

BR,
Amy
-----Original Message-----
From: jouni.nospam [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2016 5:26 AM
To: Daniele Ceccarelli
Cc: Yemin (Amy); [email-masked]; [email-masked]
Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07

Hi Daniele,

- Jouni

>>> You're right that the current draft text doesn't provide any 
>>> information
>> about the discussion.
>> 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
>> 
>> 
>> 
>> 
>>> 
>> 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
>> 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.
>>> 
>> 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
>>> 
>>> 
>> 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.
>>>>