[CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 09 September 2013 12:15 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03421E819D; Mon, 9 Sep 2013 05:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOH8gDOC0+mp; Mon, 9 Sep 2013 05:15:07 -0700 (PDT)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0E68B21E8199; Mon, 9 Sep 2013 05:14:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E741B1BCBA58; Mon, 9 Sep 2013 05:14:54 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.183.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id DC8621BCBA53; Mon, 9 Sep 2013 05:14:53 -0700 (PDT)
Message-ID: <522DBBBC.7050103@joelhalpern.com>
Date: Mon, 09 Sep 2013 08:14:52 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-ietf-ccamp-otn-g709-info-model.all@tools.ietf.org, CCAMP WG <ccamp@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-otn-g709-info-model-11.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 09 Sep 2013 12:15:21 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-ccamp-otn-g709-info-model-11.txt
Reviewer: Joel Halpern
Review Date: 9-September-2013
IETF LC End Date: 19-Sept-2013
Intended Status: Informational

Summary: I have some minor concerns about this document that I think 
should be resolved before publication.

Comments:
     In general, the document needs to be consistently clear as to what 
gaps it identifies.  Many cases are quite clear, and some are not.  I 
will try to identify the less clear cases in the comments below. The 
last paragraph of section 3.2 is clear and explicit, and what I expected 
at the end of each section.  The previous paragraph ("Specific 
information could be defined") is much less helpful.

Moderate Issues:
     It is unclear if there are gaps or requirements identified by 
sections 3.1.1 or 3.1.2.
     Given that this document is about mapping to G.709, it is unclear 
what is intended by the usage of "LSP".  My guess is that it is intended 
to mean Label Switch Paths set up by GMPLS to carry OTU/UDU elements. 
It should be stated explicitly.

Minor Issues:
     All acronyms should be expanded upon first use.
     In section 2 particularly, the OCh (Optical Channel?) should also 
be clear how that relates to the OTU and ODU being discussed.
     Figure 4 uses the abbreviation TSG, which is not defined, and not 
used elsewhere.  If it is needed in the figure, it might suffice to 
follow "TS granularity" in the caption with "(TSG)".

     Section 8 on Maximum LSP Bandwdith seems to be objecting to too 
much information leading to a "waste of bits".  While possibly of 
interest to the WG, that does not seem to fit a gap analysis.
     Similarly, section 10 on Priority Support reads as implementation 
advice rather than a gap needing protocol changes.

Nit: