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

["Adrian Farrel" <[e-mail]>]

I would say "yes", but Deborah is now cc'ed.
 
Adrian
--
Celebrate the New Year by buying someone you love a book.
Tales from the Wood - Eighteen new fairy tales
http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.
 
 
 
From: Fatai Zhang [mailto:[e-mail]] 
Sent: 20 January 2016 06:19
To: [e-mail]; 'Daniele Ceccarelli'; 'CCAMP'
Subject: RE: [CCAMP] WG Last Call on
draft-ietf-ccamp-additional-signal-type-g709v3-02 and call for sheperd
 
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:[e-mail]] 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 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:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: 19 January 2016 10:47
To: CCAMP ([e-mail])
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.
 
If anyone is willing to be the shepherd of the document, please volunteer.
 
Thanks
Daniele & Fatai