Re: [CCAMP] AD review of draft-ietf-ccamp-gmpls-g-694-lambda-labels-09

[Dan Li <[e-mail]>]

Hi Adrian,

Thanks for the AD review for this draft!

We have updated the draft-g.694-labels according to your comments, two major changes as following (except several minor editorial changes which have been accepted):
1) added the disclaimer for pre-RFC5378 work in "Copyright Notice" section;
2) added a requirement for IANA to create three subregistries (Grid, DWDM C.S. and CWDM C.S.) under "Generalized Multi-Protocol Label Switching  (GMPLS) Signaling Parameters" registry.

The updated version (10) of this draft has been posted.

Thanks,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Friday, December 10, 2010 5:47 AM
Subject: AD review of draft-ietf-ccamp-gmpls-g-694-lambda-labels-09


> Hi,
> 
> I have performed an AD review of your draft.
> 
> Don't panic!
> 
> I review all drafts that I am responsible for before putting them
> forward for IETF last call. The main objective is to catch nits and
> minor issues that would show up during the last call or in IESG
> review. The intention is to help polish your document and make sure
> it is clean and shiny so that other reviewers will stick to the
> technical details.
> 
> I think your small draft is actually a very significant contribution to
> the GMPLS family.
> 
> Most of my comments are pretty trivial, but a couple have more meat
> on them and I'd like to see a quick respin of the document before I
> issue the IETF last call. As soon as I see a new revision posted,
> I'll set the ball in motion.
> 
> Of course, all of my issues are up for discussion.
> 
> Thanks for the work,
> Adrian
> 
> ---
> 
> idnits throws up a number of minor issues...
> 
>> ** There is 1 instance of too long lines in the document, the longest
>>    one being 1 character in excess of 72.
> 
> This seems to be line 46
> 
>> == The 'Updates: ' line in the draft header should list only the
>>    _numbers_ of the RFCs which will be updated by this document (if
>>    approved); it should not include the word 'RFC' in the list.
> 
> This is in the document header...
> 
> s/Updates: RFC3471/Updates: 3471 (if approved)/
> 
>> == The document seems to lack a disclaimer for pre-RFC5378 work, but
>>    was first submitted before 10 November 2008.  Should you add the 
>>    disclaimer? (See the Legal Provisions document at
>>    http://trustee.ietf.org/license-info for more information.) 
>>    -- however, there's a paragraph with a matching beginning. 
>>    Boilerplate error?
> 
> Just need to check with you that the authors are happy to not include
> the boilerplate and are assigning the copyright. Usually not a problem,     
> but if you have trouble tracking down the authors, just add the 
> disclaimer boilerplate - it is quite safe!
> 
>> == Unused Reference: 'RFC3209' is defined on line 433, but no 
>>    explicit reference was found in the text
> 
> You can just remove the reference.
> 
> ---
> 
> The Abstract needs to be self-contained, so cannot include citations of
> RFCs or other documents.
> 
> You also need to spell out acronyms.
> 
> Can I suggest:
> 
> OLD
>   Technology in the optical domain is constantly evolving and as a 
>   consequence new equipment providing lambda switching capability has 
>   been developed and is currently being deployed. [RFC3471] has 
>   defined that a wavelength label (section 3.2.1.1) "only has 
>   significance between two neighbors" and global wavelength semantics 
>   is not considered. In order to facilitate interoperability in a 
>   network composed of next generation lambda switch-capable equipment, 
>   this document defines a standard lambda label format, which is 
>   compliant with both [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid).  
>   This document is a companion to the Generalized Multi-Protocol Label 
>   Switching (GMPLS) signaling. It defines the label format when Lambda 
>   Switching is requested in an all optical network. 
> NEW                       
>   Technology in the optical domain is constantly evolving and as a 
>   consequence new equipment providing lambda switching capability has 
>   been developed and is currently being deployed. 
>   
>   Generalized MPLS (GMPLS) is a family of protocols that can be used 
>   to operate networks built from a range of technologies including
>   wavelength (or lambda) switching. For this purpose, GMPLS defined
>   that a wavelength label only has significance between two neighbors 
>   and global wavelength semantics are not considered.
>   
>   In order to facilitate interoperability in a network composed of next
>   generation lambda switch-capable equipment, this document defines a
>   standard lambda label format that is compliant with Dense Wavelength
>   Division Multiplexing and Coarse Wavelength Division Multiplexing 
>   grids defined by the International Telecommunication Union
>   Telecommunication Standardization Sector. The label format defined in
>   this document can be used in GMPLS signaling and routing protocols.
> END
> 
> ---
> 
> You are not required to include a Table of Contents in a document of less
> than fifteen pages (but you are allowed to).
> 
> ---
> 
> Section 1
> 
> You need to expand DWDM and CWDM on first use.
> You can then remove the expansions from Section 2.
> 
> ---
> 
> Section 2
> 
> Could you capitalise the section header to match the others.
> 
> 
> ---
> 
> Section 2
> 
> s/vendor's/vendors'/
> s/consists of number/consists of a number/
> 
> ---
> 
> Section 2
> 
> s/a LSP/an LSP/
> 
> ---
> 
> Section 2 (last line)
> 
> Expand "LSR" on first use.
> 
> ---                                                                
> 
> Section 3.3
> 
>   We do not need to define a new type as the information stored is 
>   either a port label or a wavelength label. Only the wavelength label 
>   as above needs to be defined. 
> 
> This is very true, but I think the text does not belong here.
> I would try to work it into Section 3.1
> 
> ---
> 
> 
> Section 4
> 
>   This document introduces no new security considerations to [RFC3473]. 
>   For a general discussion on MPLS and GMPLS related security issues, 
>   see the MPLS/GMPLS security framework [RFC5920]. 
> 
> I think you should 
> s/[RFC3473]/[RFC3471] and [RFC3473]/
> because this I-D updates 3471.
>                                                         
> ---
> 
> Section 5
> 
> Why did you decide that there is no requirement for IANA to track the
> codepoints (Grid and C.S.) used in the DWDM and CWDM Wavelength Labels? 
> 
> It looks like you could have three registries {Grid, DWDM C.S., and 
> CWDM C.S.)
> 
> ---
> 
> Section 8
> 
> OLD
> 8. Author's Address
> NEW
> 8. Authors' Addresses
> END
> 
>