Re: [Gen-art] Genart review: draft-ietf-6man-reserved-iids-01

Robert Sparks <rjsparks@estacado.net> Mon, 01 December 2008 22:52 UTC

Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC103A685C; Mon, 1 Dec 2008 14:52:04 -0800 (PST)
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 011713A685C for <gen-art@core3.amsl.com>; Mon, 1 Dec 2008 14:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 SttTvaPcBFFg for <gen-art@core3.amsl.com>; Mon, 1 Dec 2008 14:52:03 -0800 (PST)
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 585E73A6B25 for <gen-art@ietf.org>; Mon, 1 Dec 2008 14:52:02 -0800 (PST)
Received: from dn3-232.estacado.net (dn3-232.estacado.net [172.16.3.232]) (authenticated bits=0) by estacado.net (8.14.2/8.14.1) with ESMTP id mB1MprXo055097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Dec 2008 16:51:53 -0600 (CST) (envelope-from rjsparks@estacado.net)
Message-Id: <101FF870-A531-4A91-95EB-7645B7EF811E@estacado.net>
From: Robert Sparks <rjsparks@estacado.net>
To: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <12A5D880-0299-4E1E-A2C2-04B7D2957031@nostrum.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Mon, 01 Dec 2008 16:51:53 -0600
References: <12A5D880-0299-4E1E-A2C2-04B7D2957031@nostrum.com>
X-Mailer: Apple Mail (2.929.2)
Cc: gen-art@ietf.org
Subject: Re: [Gen-art] Genart review: draft-ietf-6man-reserved-iids-01
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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org

I hit send one paragraph too soon - sorry. One additional nit below.

On Dec 1, 2008, at 4:22 PM, Robert Sparks wrote:

> 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 wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-6man-reserved-iids-01
> Reviewer: Robert Sparks
> Review Date:  01 Dec 2008
> IESG Telechat date: 04 Dec 2008
>
> Summary: This draft is basically ready for publication. I have a  
> couple of questions below.
>
> Major issues: none
>
> Minor issues:
>
> The last sentence of section 3 seems to put a (new?) normative  
> restriction on the behavior of protocols (like dhcpv6) defined in  
> other documents. Should this document call out what it's updating?
>
> Nits/editorial comments:
>
> Nit - I'm probably missing a point in the "Possible solutions"  
> section - as I read it, it is attempting to justify using a registry  
> instead of asking documents to explicitly point to the two RFCs it  
> calls out as defining reserved IID ranges because the number of  
> specifications to be updated would be large (the sentence here has a  
> grammar problem that I'll send directly to the editor). Why would  
> these same documents not need to be updated to point to the  
> registry? (I'm not disagreeing with the registry - I just don't  
> understand what is being argued in this part of the section.)
>

Nit - The first sentence in the security considerations section is  
confusing. To me it says 'standard track rfcs that change this  
registry need to be authenticated and authorized'. What does it really  
intend to say?
>

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art