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

[Yemin (Amy)]

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:jouni.nos...@gmail.com] 
Sent: Wednesday, October 19, 2016 5:26 AM
To: Daniele Ceccarelli
Cc: Yemin (Amy); gen-art@ietf.org; 
draft-ietf-ccamp-ospf-availability-extension@ietf.org
Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07

Hi Daniele,


> On Oct 17, 2016, at 11:28 PM, Daniele Ceccarelli 
>  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:jouni.nos...@gmail.com]
>> Sent: martedì 18 ottobre 2016 08:23
>> To: Yemin (Amy) 
>> Cc: gen-art@ietf.org; draft-ietf-ccamp-ospf-availability-
>> extension@ietf.org
>> Subject: Re: Gen-ATR review of 
>> draft-ietf-ccamp-ospf-availability-extension-
>> 07
>> 
>> Hi,
>> 
>>> On Oct 17, 2016, at 8:16 PM, Yemin (Amy) 
>> 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.
>>> 

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

[jouni.nospam]

Hi Daniele,


> On Oct 17, 2016, at 11:28 PM, Daniele Ceccarelli 
>  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:jouni.nos...@gmail.com]
>> Sent: martedì 18 ottobre 2016 08:23
>> To: Yemin (Amy) 
>> Cc: gen-art@ietf.org; draft-ietf-ccamp-ospf-availability-
>> extension@ietf.org
>> Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-
>> 07
>> 
>> Hi,
>> 
>>> On Oct 17, 2016, at 8:16 PM, Yemin (Amy) 
>> 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:jouni.nos...@gmail.com]
>>> Sent: Monday, October 17, 2016 11:21 PM
>>> To: Yemin (Amy)
>>> Cc: gen-art@ietf.org;
>>> draft-ietf-ccamp-ospf-availability-extension@ietf.org
>>> Subject: Re: Gen-ATR review of
>>> draft-ietf-ccamp-ospf-availability-extension-07
>>> 
>>> Hi,
>>> 
>>> 
 On Oct 17, 2016, at 1:06 AM, Yemin (Amy) 
>> 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: 

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

[Daniele Ceccarelli]

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:jouni.nos...@gmail.com]
> Sent: martedì 18 ottobre 2016 08:23
> To: Yemin (Amy) 
> Cc: gen-art@ietf.org; draft-ietf-ccamp-ospf-availability-
> extension@ietf.org
> Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-
> 07
> 
> Hi,
> 
> > On Oct 17, 2016, at 8:16 PM, Yemin (Amy) 
> 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:jouni.nos...@gmail.com]
> > Sent: Monday, October 17, 2016 11:21 PM
> > To: Yemin (Amy)
> > Cc: gen-art@ietf.org;
> > draft-ietf-ccamp-ospf-availability-extension@ietf.org
> > Subject: Re: Gen-ATR review of
> > draft-ietf-ccamp-ospf-availability-extension-07
> >
> > Hi,
> >
> >
> > > On Oct 17, 2016, at 1:06 AM, Yemin (Amy) 
> 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: gen-art@ietf.org
> > > 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
> > >
> > > .
> > >
> > > Document: draft-ietf-ccamp-ospf-availability-extension-07
> > > Reviewer: Jouni 

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

[jouni.nospam]

Hi,

> On Oct 17, 2016, at 8:16 PM, Yemin (Amy)  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:jouni.nos...@gmail.com] 
> Sent: Monday, October 17, 2016 11:21 PM
> To: Yemin (Amy)
> Cc: gen-art@ietf.org; 
> draft-ietf-ccamp-ospf-availability-extension@ietf.org
> Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07
>  
> Hi,
>  
>  
> > On Oct 17, 2016, at 1:06 AM, Yemin (Amy)  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: gen-art@ietf.org
> > 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
> > 
> > .
> > 
> > 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: 

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

[Yemin (Amy)]

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:jouni.nos...@gmail.com]
Sent: Monday, October 17, 2016 11:21 PM
To: Yemin (Amy)
Cc: gen-art@ietf.org; draft-ietf-ccamp-ospf-availability-extension@ietf.org
Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07



Hi,





> On Oct 17, 2016, at 1:06 AM, Yemin (Amy) 
> > 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: gen-art@ietf.org

> 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

>

> .

>

> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[jouni.nospam]

Hi,


> On Oct 17, 2016, at 1:06 AM, Yemin (Amy)  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: gen-art@ietf.org
> 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
> 
> .
> 
> 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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Yemin (Amy)]

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:jouni.nos...@gmail.com] 
Sent: Monday, October 17, 2016 5:50 AM
To: gen-art@ietf.org
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

.

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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[jouni.nospam]

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

.

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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art