[CCAMP] Gen-art Telechat review: draft-ietf-ccamp-flexigrid-lambda-label-05

[Robert Sparks <[e-mail]>]

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-flexigrid-lambda-label
Reviewer: Robert Sparks
Review Date: 14 Sep 2015
IETF LC End Date: past
IESG Telechat date: 17 Sep 2015

Summary: (still) Ready for publication as Proposed Standard

Thanks for the improvements in -05.

On 9/2/15 3:04 PM, Robert Sparks wrote:
> 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-flexigrid-lambda-label-04
> Reviewer: Robert Sparks
> Review Date: 2 Sep 2015
> IETF LC End Date: 9 Sep 2015
> IESG Telechat date: Not yet scheduled for a telechat
>
> Summary: Ready for publication as a Proposed Standard
>
> One thing I'd like to check, and I suspect this pokes at a 
> conversation that has already happened (as hinted in the 
> acknowledgements section):
>
> The discussion of managements systems having to deal with a 64 bit 
> wavelength label caught my eye. This is an RFC3471 section 3.2.1.1 
> label isn't it? That document shows wavelength labels as 32 bit 
> things. Has something updated 3471 to say to expect a multiple of 32 
> bits, and not 32 bits specifically? If not, maybe this document would 
> be a good place to do so explicitly, rather than what appears to be 
> fiat at the moment?
>
> micro-nit: at the end of the introduction "in that regard" suggests 
> the document updates the work of the ITU-T in some other regard? I 
> suggest simple deleting the phrase.
>
>
>
>