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

Adrian Farrel <Adrian.Farrel@huawei.com> Thu, 09 December 2010 21:45 UTC

Return-Path: <Adrian.Farrel@huawei.com>
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A59128C113 for <ccamp@core3.amsl.com>; Thu, 9 Dec 2010 13:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.424
X-Spam-Level:
X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE4prTX8E9fQ for <ccamp@core3.amsl.com>; Thu, 9 Dec 2010 13:45:44 -0800 (PST)
Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 46B603A6818 for <ccamp@ietf.org>; Thu, 9 Dec 2010 13:45:44 -0800 (PST)
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LD600KBLKIP02@usaga01-in.huawei.com> for ccamp@ietf.org; Thu, 09 Dec 2010 13:47:13 -0800 (PST)
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LD600DEPKIHLD@usaga01-in.huawei.com> for ccamp@ietf.org; Thu, 09 Dec 2010 13:47:13 -0800 (PST)
Date: Thu, 09 Dec 2010 21:47:04 +0000
From: Adrian Farrel <Adrian.Farrel@huawei.com>
To: danli@huawei.com, tm-otani@kddi.com, rabbat@alum.mit.edu, sidney.shiba@yahoo.com, hongxiang.guo@gmail.com, miyazaki.keiji@jp.fujitsu.com, diego.caviglia@ericsson.com, tsuri@kddilabs.jp
Message-id: <06ea01cb97ea$a3b57230$eb205690$@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Outlook 14.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-gb
Content-transfer-encoding: 7bit
Thread-index: AcuX6n+MNNbZM5IIR9SmyV2wqTy1aw==
Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org
Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-g-694-lambda-labels-09
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian.Farrel@huawei.com
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Dec 2010 21:45:45 -0000

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