Re: [Gen-art] Gen-ART review of draft-ietf-ccamp-attribute-bnf-02

Lou Berger <lberger@labn.net> Tue, 18 October 2011 21:56 UTC

Return-Path: <lberger@labn.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597A121F8BA0 for <gen-art@ietfa.amsl.com>; Tue, 18 Oct 2011 14:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.015
X-Spam-Level:
X-Spam-Status: No, score=-100.015 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, 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 xwcAGQMsYzrO for <gen-art@ietfa.amsl.com>; Tue, 18 Oct 2011 14:56:13 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id B36E821F8B9F for <gen-art@ietf.org>; Tue, 18 Oct 2011 14:56:13 -0700 (PDT)
Received: (qmail 19196 invoked by uid 0); 18 Oct 2011 21:56:13 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 18 Oct 2011 21:56:13 -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:CC:To:MIME-Version:From:Date:Message-ID; bh=qKqZM1bEz3RuCrLRm/ekH0HsnpKF4xqHVLWY4EjgR2g=; b=1m10E+G4o2Xoc5I8wHhT29uKodeF/WM/flTboO5073SdKb5Rfv+g7+Lh6k991Cocy4q0t+MgkJAF8oZS6wuN6ah2HCSmmuuufX/8vxvNBfB4hNEjma4H5sZYQIgsBmec;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from <lberger@labn.net>) id 1RGHds-0007Zp-Oc; Tue, 18 Oct 2011 15:56:12 -0600
Message-ID: <4E9DF5FD.9060407@labn.net>
Date: Tue, 18 Oct 2011 17:56:13 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
References: <4E9C9BA2.1040801@bell-labs.com>
In-Reply-To: <4E9C9BA2.1040801@bell-labs.com>
X-Enigmail-Version: 1.0.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 69.89.31.113 authed with lberger@labn.net}
Cc: Adrian Farrel <adrian@olddog.co.uk>, General Area Review Team <gen-art@ietf.org>, draft-ietf-ccamp-attribute-bnf@tools.ietf.org, dbrungard@att.com
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ccamp-attribute-bnf-02
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 18 Oct 2011 21:56:14 -0000

Vijay,

Please see below.

On 10/17/2011 5:18 PM, Vijay K. Gurbani wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-ccamp-attribute-bnf-02
> Reviewer: Vijay K. Gurbani
> Review Date: Oct-17-2011
> IETF LC End Date: Not known.
> IESG Telechat date: Oct-20-2011
> 
> Summary: This draft is ready as a Proposed Standard.
> 
> Major issues: 0
> Minor issues: 2
> Nits/editorial comments: 3
> 
> Minor:
> * S2: In the phrase, "... implementations must be capable ..."
>   is this a normative MUST?
> 
> * S3: In the phrase, "... implementations must be capable ..."
>   is this a normative MUST?
> 

These are both in text quoted from RFC5420, so the comment applies to
that RFC.  Clearly we can't change it in this document. (BTW usage of
'must' as in the English/informative usage is still legitimate.)

> Nits:
> * Abstract: s/how LSP attribute are/how LSP attributes are/
> 

"LSP Attributes" is a term/name defined in RFC5420.

This does point out that in three places in the document, the following
is needed:
 s/LSP attributes/LSP Attributes

> * S1: "Two LSP Attributes related objects ..." --- This reads
>   funny.  Did you mean "Two LSP Attribute related objects..."?
>   This oversight, if indeed it is an oversight, is repeated else-
>   where in the document as well.
> 
>   At other places (e.g., S3.2.1), you simply use "LSP Attribute object".
>   So I am not sure which one is correct.
> 

good catch!  it should be:
s/LSP Attribute/LSP Attributes

> * S2.1: s/LSP attributed related objects/LSP attributes related objects/
>    or maybe "LSP Attribute related objects"?

another good catch:
 s/LSP attributed/LSP Attributes
> 
> - vijay

Much thanks!

Lou