Gen-Art LC review for draft-cotton-rfc4020bis-01

Robert Sparks <rjsparks@nostrum.com> Wed, 11 September 2013 22:04 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DBF11E8106; Wed, 11 Sep 2013 15:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.521
X-Spam-Level:
X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, SUBJECT_FUZZY_TION=0.156, 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 vRQZm-aVRxEY; Wed, 11 Sep 2013 15:04:25 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D431A11E80E9; Wed, 11 Sep 2013 15:04:24 -0700 (PDT)
Received: from unnumerable.local (pool-173-71-52-22.dllstx.fios.verizon.net [173.71.52.22]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8BM4HGt041840 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Wed, 11 Sep 2013 17:04:18 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <5230E8E1.4040701@nostrum.com>
Date: Wed, 11 Sep 2013 17:04:17 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, draft-cotton-rfc4020bis@tools.ietf.org, "ietf@ietf.org" <ietf@ietf.org>
Subject: Gen-Art LC review for draft-cotton-rfc4020bis-01
Content-Type: multipart/alternative; boundary="------------070407010709060709010706"
Received-SPF: pass (shaman.nostrum.com: 173.71.52.22 is authenticated by a trusted mechanism)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2013 22:04:26 -0000

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-cotton-rfc4020bis-01
Reviewer: Robert Sparks
Review Date: 2013-09-11
IETF LC End Date: 2013-09-24
IESG Telechat date: not scheduled

Summary: This draft is on the right track but has open issues, described 
in the review.

(That summary was taken from the options in RFC6385. I would prefer to say
"There is one minor issue that is bigger than a nit, but it should be 
easy to straighten out")

Issue : Section 2 is very confusing. It starts out listing 4 things that 
look like they all have to be met. But then the last sentence confuses 
things. Is just reinforcing that both a and b have to be met (if so, 
then wouldn't things also stop if c and d weren't met? (see 3.1 step2)).
I suggest replacing "If conditions (a) or (b)" with "If any of the above 
conditions"

Nit 1: Section 3.1 reads harshly at the transition from step 4 to step 
5.  It leaves it implicit that the AD has to approve.
Step 3 has  "if steps 2 and 3 are satisfied". 4020 said "with the 
approval of the Area Director(s)". Adding that text  to step 5 would 
address the nit.

Nit 2: The introduction contains a bit of text that it carried forward, 
slightly modified, from 4020 for which I suggest further modification:
replace
"the IETF community wishes to retain tight control of the protocol"
with
"the IETF community has consensus to retain tight control of the 
registry content"

That way this document is reflecting the actual process point that would 
lead to a tighter registration policy without trying to speculate what 
motivated that consensus.

Nit 3: Several reviewers have pointed to a lack of clarity in section 2 a.
I suggest taking the change John Klensin proposed (with tweaks as below)
> 	The code points must normally be from a space designated
> 	as "RFC Required", "IETF Review", or "Standards Action".
> 	In addition, code points from a "Specification
> 	Required" space are allowed if the specification will be
> 	published as an RFC.