[Gen-art] Gen-ART LC review of draft-ietf-ccamp-gmpls-ason-routing-ospf-07

Ben Campbell <ben@estacado.net> Thu, 12 March 2009 20:38 UTC

Return-Path: <ben@estacado.net>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F01228C128 for <gen-art@core3.amsl.com>; Thu, 12 Mar 2009 13:38:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599]
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 gtrjqqy1HKM2 for <gen-art@core3.amsl.com>; Thu, 12 Mar 2009 13:38:20 -0700 (PDT)
Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 38DA828C0D6 for <gen-art@ietf.org>; Thu, 12 Mar 2009 13:38:19 -0700 (PDT)
Received: from [10.0.1.197] (adsl-68-94-28-248.dsl.rcsntx.swbell.net [68.94.28.248]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n2CKcjec011414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Mar 2009 15:38:50 -0500 (CDT) (envelope-from ben@estacado.net)
Message-Id: <F527A936-D8E7-4109-8E2F-38A4F2A40203@estacado.net>
From: Ben Campbell <ben@estacado.net>
To: dimitri.papadimitriou@alcatel-lucent.be, General Area Review Team <gen-art@ietf.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 12 Mar 2009 15:38:45 -0500
X-Mailer: Apple Mail (2.930.3)
Cc: rcallon@juniper.net, Adrian Farrel <adrian@olddog.co.uk>, dward@cisco.com
Subject: [Gen-art] Gen-ART LC review of draft-ietf-ccamp-gmpls-ason-routing-ospf-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2009 20:38:22 -0000

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ccamp-gmpls-ason-routing-ospf-07
Reviewer: Ben Campbell
Review Date: 2009-03-12
IETF LC End Date: 2009-03-13
IESG Telechat date: (if known)

Summary:

This draft is very close to ready for publication as an experimental  
RFC. I found one minor issue with the IANA considerations that should  
be fixed first. I also have a few comments related to editorial issues  
and nits.

Major issues:

None

Minor issues:

-- Section 9.1:

This section shows the sub-TLV types as TBD, but at least some of the  
references sections specify type numbers.

Nits/editorial comments:

-- general:

It would be helpful to have referenceable numbers for the TLV format  
figures.

Using non-mnemonic citations as if they were nouns in a sentence  
creates extra work for the reader, who must flip back to the  
references to understand the sentence.  That is, the form  "...defined  
in [xxx]".  It's better to say "defined in foo [xxx]". It's not as bad  
with mnemonic citations (e.g. "defined in [foo]"), but it can still  
cause confusion if text is quoted in other documents without the  
associated reference section.

-- section 2, 2nd paragraph: "The
    limit of the subdivision results is an RA that contains just two
    sub-networks interconnected by a single link."

I don't follow the last sentence. Is it possible "results is" was  
meant to be "results in"?

-- section 3.1, last paragraph, first sentence: "The local addresses  
that can be learned from Opaque TE LSAs."

incomplete sentence. Is "that" spurious?

section 3.2, first paragraph after the figure: "Length is set to Sum[n] 
[4 + #32-bit words/4] where n is the
        number of local prefixes included in the sub-TLV."

I'm not sure I understand the expression.

-- section 4.1, 3rd paragraph:

Please expand LSC and PSC on first use.

-- section 6, 3rd paragraph:

s/informtation/information

-- idnits reports the following:

>   == You're using the IETF Trust Provisions Section 6.b License  
> Notice from
>      10 Nov 2008 rather than the newer Notice from 12 Feb 2009.   
> Both versions
>      are accepted up to the end of March 2009; after that you'll  
> need to use
>      the 12 Feb 2009 Notice.  (See http://trustee.ietf.org/license-info/)
>
>   == 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.).
>