[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.). >
- [Gen-art] Gen-ART LC review of draft-ietf-ccamp-g… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-cca… Adrian Farrel
- Re: [Gen-art] Gen-ART LC review of draft-ietf-cca… PAPADIMITRIOU Dimitri
- Re: [Gen-art] Gen-ART LC review of draft-ietf-cca… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-cca… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-cca… Adrian Farrel
- Re: [Gen-art] Gen-ART LC review of draft-ietf-cca… Ben Campbell