[CCAMP] WG Last Call comments on draft-ietf-ccamp-otn-g709-info-model-04

Lou Berger <lberger@labn.net> Fri, 19 October 2012 23:06 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 C1CFD21F8852 for <ccamp@ietfa.amsl.com>; Fri, 19 Oct 2012 16:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.429
X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=1.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IFQX-NACvjmu for <ccamp@ietfa.amsl.com>; Fri, 19 Oct 2012 16:06:10 -0700 (PDT)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com []) by ietfa.amsl.com (Postfix) with SMTP id 0423921F8850 for <ccamp@ietf.org>; Fri, 19 Oct 2012 16:06:09 -0700 (PDT)
Received: (qmail 13629 invoked by uid 0); 19 Oct 2012 23:05:47 -0000
Received: from unknown (HELO box313.bluehost.com) ( by oproxy12.bluehost.com with SMTP; 19 Oct 2012 23:05:47 -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=PPNaho0f18H3LOgDIZStWFMYfeZuhC/05dTvgPQWJjE=; b=TcnHiC7VILenNAbDUdcgIvxbS+1ix50XXufZef6IlJKVQObO6pBCL+BuPEeRpgy3YXO8ThLms/DKrWQnvBESUziN67e4EsKAusjcX/xE4x33uZ+M1HKsLS2pR9WhX7OP;
Received: from box313.bluehost.com ([]:37741 helo=[]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1TPLdT-0002nn-Ld; Fri, 19 Oct 2012 17:05:47 -0600
Message-ID: <5081DCC6.1010409@labn.net>
Date: Fri, 19 Oct 2012 19:05:42 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: CCAMP <ccamp@ietf.org>, draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org
References: <50733BED.8090304@labn.net>
In-Reply-To: <50733BED.8090304@labn.net>
X-Enigmail-Version: 1.4.5
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] WG Last Call comments on draft-ietf-ccamp-otn-g709-info-model-04
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, 19 Oct 2012 23:06:10 -0000

	I have the following LC comments:

General comments:

- There's a lot of text/concepts that is common to both this document
and the framework document.  The document certainly adds additional
useful detail, but I'm not sure it's really provides an information
model of any kind.  Optimally, I think this document should be merged
with the framework document.  I think this would yield a more
comprehensive and understandable result.  I really don't see this as a
lot of work/time, although it clearly would be a major change.

If this is considered to be to onerous a proposal, then this document
should at least be updated to (a) reduce duplication text with the
framework document and (b) remove any references to "model" and just
talk about providing "Additional Information"

- The document should be reviewed by the authors to ensure it is
consistent with the latest solutions documents and WG discussions.  For
example, there are multiple references to the contentious and much
discussed "penultimate hop" case without any references to the agreed
upon approach.

Editorial comments:

- Please verify that abbreviations are defined before being used .
There are a number of these.

- Please use a consistent decimal representation (sometimes commas are
used other times periods)

- the references [G709-v1] and [G709-v3] each actually refer to multiple
documents, each documented needs to have it's own (correct) reference,
i.g., [G709-v1] and [G709-v1a1]. The document text will need to be
revisited to ensure the proper reference is made.

shows there are unresolved nits that need to resolved .  I'm using line
numbers from this url in my subsequent comments.

Line 18: Suggest dropping "The recent revision of"

Line 20/21: Suggest dropping the marketing phrase "enabling optimized
support for an increasingly abundant service mix."

Lines 93-127 (through "of"): I don't see how this text provides any
value.  I suggest dropping it, or at most just reference the FWK document.

Lines 319-341: Instances of "G.709" should be "[G.709-V3]"

Line 538: Add "(Source: Table 7-10 [G.709-V3])"

Lines 579/80: Does "foundation G.709" mean "[G.709-V1]" If not what does
it mean?

Line 591: Replace/add "[RFC4203]" after "OSPF-TE"

Lines 617-620: While one could certainly implement 4202/3 this way, it
certainly is not required.  I think these lines should be dropped.

Lines 626-630:  These sentences are simply wrong.  What would be correct
is to say something like:

"Per [RFC2328], OSPF messages are directly encapsulated in IP datagrams
and depend on IP fragmentation when transmitting packets larger than the
network MTU.  [RFC2328] recommends that "IP fragmentation should be
avoided whenever possible." This recommendation further constraints
solutions as OSPF does not support any generic mechanism to fragment

Line 632, probably should add a reference to [RFC4201].

Lines 733, 735, 764: figure numbers are wrong "6"->"9", "7"->"10"

Lines 734/5: "are supposed to" --> "only"

Line 735: "The figure 6 addresses" --> "Figure 9 represents"

Line 738: Assuming I understand your intent, replace "Being D a single
stage capable node" --> "As node D is a single stage capable node"

Section 5, needs to be updated to reference existing relevant signaling
and routing GMPLS RFCs and identify any additional information that is
being conveyed and additional risks, if any.

That's it on this document.


On 10/8/2012 4:47 PM, Lou Berger wrote:
> This mail begins a two week working group last call on:
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-09
> (Informational)
> http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-04
> (Informational)
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03
> (Standards Track)
> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-04
> (Standards Track)
> This working group last call ends on October 22.  Comments should be
> sent to the CCAMP mailing list.  Please remember to include the
> technical basis for any comments.
> Please note that we're still missing a few IPR statements, and look
> for these to come in during the LC period.  Any forthcoming publication
> request will be delayed by late IPR statements/disclosures.
> Thank you,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp