Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 19 Jan 2016 10:47:27 +0000

Working group,

Thanks to the prompt reply from the authors we're ready to start the WG last for this document.

This starts a two weeks working group last call on draft-ietf-ccamp-additional-signal-type-g709v3-02.
The last call ends on Tuesday  February 2nd.
Please send your comments to the CCAMP mailing list.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-additional-signal-type-g709v3/history/
Please note that no IPR was disclosed against this draft.

If anyone is willing to be the shepherd of the document, please volunteer.

Thanks

Daniele & Fatai

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Jan 2016 17:46:14 -0000

Thanks Daniele.
 
It would be nice as a general principle to have the document nit-free before
last call, but anyway, the authors can handle that as part of the last call
comments and make the necessary fixes before the I-D goes forward. Maybe the
same applies to the formatting, page breaks and so on?
 
I reviewed and commented on this document some time back and it appears to be
much better now. Thanks to the authors.
 
Here are some nits...
 
The Abstract is full of abbreviations that will need to be expanded.
 
The text uses the term "draft" to describe itself. If you change this to be
"document" it will remain consistent when the I-D becomes an RFC.
 
It would be nice if the IANA considerations section gave IANA a little more
help. Specifically...
IANA maintains a registry called "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" with a subregistry called "OTN Signal Type". IANA
is requested to make three further allocations from that registry as follows.
You might also give IANA guidance about which numbers to allocate as they will
want to know whether to use the unassigned values in the 12-19 range or values
in the 23-255 range. They will also wonder about 5.
 
I don't see how G.sup43 can be other than a normative reference. It looks to me
from http://www.itu.int/itu-t/recommendations/rec.aspx?rec=11321 that the
revision you reference is actually in force (i.e., not "for agreement").
 
And lastly (I'm sure we've had this discussion before) the registry is marked
with the Registration Procedure "Standards Action" yet this document is marked
as "Informational". That will mean that IANA will (should) refuse to assign the
code points.
 
Cheers,
Adrian

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 19 January 2016 10:47
To: CCAMP ([email-masked])
Subject: [CCAMP] WG Last Call on
draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd
 
Working group,
 
Thanks to the prompt reply from the authors we're ready to start the WG last for
this document. 
 
This starts a two weeks working group last call on
draft-ietf-ccamp-additional-signal-type-g709v3-02.
The last call ends on Tuesday  February 2nd. 
Please send your comments to the CCAMP mailing list.
 
All the IPR declarations from authors and contributors have been collected and
can be found in the history of the document: 
https://datatracker.ietf.org/doc/draft-ietf-ccamp-additional-signal-type-g709v3/
history/ 
Please note that no IPR was disclosed against this draft.

Thanks
Daniele & Fatai

---

From: Fatai Zhang <[email-masked]>
Date: Wed, 20 Jan 2016 06:18:35 +0000

Hi Adrian,

Thanks for your review.

I just have one question to confirm my understanding.

We know that G.sup43 is a non-normative recommendation defined by ITU-T SG15, is it valid to define a "Standards Track" RFC for G.sup43?

Best Regards

Fatai

From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Wednesday, January 20, 2016 1:46 AM
To: 'Daniele Ceccarelli'; 'CCAMP'
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Thanks Daniele.

It would be nice as a general principle to have the document nit-free before last call, but anyway, the authors can handle that as part of the last call comments and make the necessary fixes before the I-D goes forward. Maybe the same applies to the formatting, page breaks and so on?

I reviewed and commented on this document some time back and it appears to be much better now. Thanks to the authors.

Here are some nits...

The text uses the term "draft" to describe itself. If you change this to be "document" it will remain consistent when the I-D becomes an RFC.

It would be nice if the IANA considerations section gave IANA a little more help. Specifically...
IANA maintains a registry called "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" with a subregistry called "OTN Signal Type". IANA is requested to make three further allocations from that registry as follows.
You might also give IANA guidance about which numbers to allocate as they will want to know whether to use the unassigned values in the 12-19 range or values in the 23-255 range. They will also wonder about 5.

I don't see how G.sup43 can be other than a normative reference. It looks to me from http://www.itu.int/itu-t/recommendations/rec.aspx?rec=11321 that the revision you reference is actually in force (i.e., not "for agreement").

And lastly (I'm sure we've had this discussion before) the registry is marked with the Registration Procedure "Standards Action" yet this document is marked as "Informational". That will mean that IANA will (should) refuse to assign the code points.

Cheers,
Adrian

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: 19 January 2016 10:47
To: CCAMP ([email-masked]<mailto:[email-masked]>)
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Working group,

Thanks

Daniele & Fatai

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 20 Jan 2016 20:59:57 +0000

Thanks, Adrian. We'll make the changes you suggest after LC (the G.sup43 one pending confirmation).

Cheers

Matt

From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, January 19, 2016 12:46 PM
To: 'Daniele Ceccarelli' <[email-masked]>; 'CCAMP' <[email-masked]>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Thanks Daniele.

Here are some nits...

Cheers,
Adrian

Working group,

Thanks

Daniele & Fatai

---

From: "Matt Hartley (mhartley)" <[email-masked]>
Date: Wed, 20 Jan 2016 21:00:19 +0000

Support (as co-author)

Cheers

Matt

From: CCAMP [mailto:[email-masked]] On Behalf Of Daniele Ceccarelli
Sent: Tuesday, January 19, 2016 5:47 AM
To: CCAMP ([email-masked]) <[email-masked]>
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Working group,

Thanks

Daniele & Fatai

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 Jan 2016 09:01:11 +0000

Matt, authors,

Some more comments from my side.

-Abstract:  Please substitute GMPLS with RSVP-TE, we're just defining new values for RSVP-TE, not the whole GMPLS suite.  (Are you planning to define also extensions to OSPF? It's a bit weird to be able to signal something but not to advertise it).

-Introduction: I'd substitute "ODU-related" with "the digital layer of the G.709 OTN", or "the Optical Channel Data Unit"

-Introduction: same comment as abstract

-Normative reference: RFC7139 occurs twice.

-Intended status: I think that draft has to be standard track. Even if g.sup43 is not a standard document we're defining a standard behavior for RSVP-TE.

Thanks
Daniele

From: Matt Hartley (mhartley) [mailto:[email-masked]]
Sent: mercoledì 20 gennaio 2016 22:00
To: [email-masked]; Daniele Ceccarelli; 'CCAMP'
Cc: Matt Hartley (mhartley)
Subject: RE: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Cheers

Matt

From: CCAMP [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Tuesday, January 19, 2016 12:46 PM
To: 'Daniele Ceccarelli' <[email-masked]<mailto:[email-masked]>>; 'CCAMP' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Thanks Daniele.

Here are some nits...

Cheers,
Adrian

Working group,

Thanks

Daniele & Fatai

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 Jan 2016 09:44:24 +0000

Hi Dieter,

I don't think here the point is whether g.sup43 is normative or informative. We're defining an extension to a protocol, and:

-          If an implementation wants to claim compatibility to the RFCtobe, the extension MUST be supported by the implementation

-          If we want the IANA to assign a code, the document needs to be standard track.

BR
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: giovedì 21 gennaio 2016 09:29
To: Fatai Zhang; [email-masked]; Daniele Ceccarelli; 'CCAMP'
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Hi Adrian, all,

I concur with Fatai.

The rules concerning supplements are provided in ITU-T recommendation A.13, see:

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=5280

There you find:

2.4          Supplements are only informative and are therefore not considered to be an integral part of any Recommendation(s).

Thanks,
Dieter

On 20.01.2016 07:18, Fatai Zhang wrote:
Hi Adrian,

Thanks for your review.

Best Regards

Fatai

Thanks Daniele.

Here are some nits...

Cheers,
Adrian

Working group,

Thanks

Daniele & Fatai

_______________________________________________

CCAMP mailing list

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

https://www.ietf.org/mailman/listinfo/ccamp

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 21 Jan 2016 11:57:43 +0000

Hi Dieter,

Sorry for misunderstanding your point.
Regarding the informative vs normative reference we have some guidelines (sometimes to be interpreted): https://www.ietf.org/iesg/statement/normative-informative.html

Where:

-      Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.

-      An informative reference is not normative; rather, it only provides additional information. For example, an informative reference might provide background or historical information. Informative references are not required to implement the technology in the RFC.

What is clear is that Normative or Informative does not refer to the referenced document per se (a normative document can be informative with respect to a draft and viceversa).

The question is: does an implemented need to know all the g.sup43 details to implement this draft? Or simply get the codes and put them into RSVP-TE? For sure G.709 and G.sup43 fall under the same category.

BR
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: giovedì 21 gennaio 2016 10:54
To: Daniele Ceccarelli; Fatai Zhang; [email-masked]; 'CCAMP'
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Hi Daniele, all,
On 21.01.2016 10:44, EXT Daniele Ceccarelli wrote:
Hi Dieter,

-          If we want the IANA to assign a code, the document needs to be standard track.
I was not questioning the IETF status of this draft that is in WG LC.

The point I was trying to make is that ITU-T Recommendation G.Sup43 is informative only. Therefore it looks a bit strange to me that
G.Sup43 shall be listed as normative reference in the draft/RFC. But, others may know better how to handle this properly from an IETF
rules perspective.

Thanks,
Dieter

BR
Daniele

From: Dieter Beller [mailto:[email-masked]]
Sent: giovedì 21 gennaio 2016 09:29
To: Fatai Zhang; [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli; 'CCAMP'
Subject: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd

Hi Adrian, all,

I concur with Fatai.

There you find:

Thanks,
Dieter

Thanks for your review.

Best Regards

Fatai

Thanks Daniele.

Here are some nits...

Cheers,
Adrian

Working group,

Thanks

Daniele & Fatai

CCAMP mailing list