[CCAMP] 2nd WG Last Call comments on g709-framework (editorial only)

Lou Berger <lberger@labn.net> Fri, 14 June 2013 20:04 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1421921F9D21 for <ccamp@ietfa.amsl.com>; Fri, 14 Jun 2013 13:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E5hnmPGumCPM for <ccamp@ietfa.amsl.com>; Fri, 14 Jun 2013 13:04:01 -0700 (PDT)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com []) by ietfa.amsl.com (Postfix) with SMTP id 69B9021F9D2B for <ccamp@ietf.org>; Fri, 14 Jun 2013 13:04:01 -0700 (PDT)
Received: (qmail 18987 invoked by uid 0); 14 Jun 2013 20:03:32 -0000
Received: from unknown (HELO box313.bluehost.com) ( by oproxy9.bluehost.com with SMTP; 14 Jun 2013 20:03:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=clazJOolUm3f2eYts5XL4cl2DvIh82c1OIXz3fsiJD8=; b=C9Cfb7Oa/BkGrYfnRFB+n/ym2IgMZPyu1GYIPZgmu82xOmlEaWFRbp+N5btuJZ3ynNgI3GErfUludqZVR3eyUo086YsnPqriljWuWX79S/lHrAuDndMDHozfy7LLpp+p;
Received: from box313.bluehost.com ([]:52535 helo=[]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UnaDb-0006su-LI; Fri, 14 Jun 2013 14:03:31 -0600
Message-ID: <51BB7710.2020009@labn.net>
Date: Fri, 14 Jun 2013 16:03:28 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org" <draft-ietf-ccamp-gmpls-g709-framework@tools.ietf.org>
References: <51A8CB9D.40009@labn.net>
In-Reply-To: <51A8CB9D.40009@labn.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth authed with lberger@labn.net}
Subject: [CCAMP] 2nd WG Last Call comments on g709-framework (editorial only)
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: Fri, 14 Jun 2013 20:04:06 -0000

	The following are comments as part of my LC review of
draft-ietf-ccamp-gmpls-g709-framework-12.  Note that I'm the document
shepherd, see RFC 4858 for more information.

I only have editorial nits, which should be picked up in the next
revision of this document.

The most major comment I have is that this and the other g709v3
documents should be consistent in usage of "TS granularity" versus
"TSG".  Sometimes one is used rather than the other, sometimes both are
used in the same document (as is the case in this document).  Please
pick either one and update the four documents to be consistent.

Another and related comment is please define and use a consistent plural
form of "TS".  You initially define "TSs" to expand to "Time Slots", but
then use "TS" as the plural form in many (but not all cases).  I
personally think "TSs" in all plural cases makes the most sense.

Line numbers in the following comments can be found at

Line 96: "suite including provision [RFC4328] provides"
 This sentence is broken and should be rephrased.  perhaps you mean
 something like:
  The GMPLS signaling extensions defined in [RFC4328] provide the
  mechanisms for basic GMPLS control of OTN networks based on the 2001
  revision of the G.709 specification.

Line 98/9: this is pretty awkward, how about:
  Later revisions of the G.709 specification, i.e., [G709-2012], has
  included some new features
  The 2012 revision of the G.709 specification, [G709-2012], includes
  new features

Line 143:
  Does it make sense to mention PPM here? suggest dropping.
  Also need to expand acronym on initial use.

Section 3
  Given the discussion on the signaling document I think it's worth
  adding a few words and a reference to [G7041] in this section.

Line 258:
  s/granularity and/granularity,

Line 272:
  s/the 'new' equipment will/[G709-2012] requires 'new' equipment

Line 273:

Line 313:

Lines 388/9:
  I think the terminology "flexible optical connections" is not well
  defined in this context.  Either add a reference or drop the word

Line 390:
  Add a reference defining 3R.  How about adding ", see [RFC6163] for
  additional information." to the end of the line?

Line 438 & 510:
  Add references for MLN.

Line 571-579:
  Given the documented signaling approach, does it still make sense to
  mention tolerance here?

Line 590:
  What is a TS type, perhaps you mean "TSG"?

Line 598:
  s/in order to setting up/in order to set up

Line 604/5
 A new extension object has to be defined
 A signaling mechanism must be identified

Line 667:
 s/of TS/of each TS

Line 681
 Suggest dropping "and sufficient" as it is completely unclear what
 this means.

Line 721:
 remove redundant text "either no priorities or"

Lines 752-755:
  I'm not sure what value this paragraph provides as LMP information is
  generally available from the management plane (e.g., configuration).

Line 758

Line 761:
  s/the discovering procedure by LMP/discovery via LMP

Line 857:
  Need a reference for "TS auto-negotiation is supported"

That's it,