[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