[renum] Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
Robert Sparks <rjsparks@nostrum.com> Tue, 30 April 2013 16:32 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F74321F9BA3; Tue, 30 Apr 2013 09:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.198
X-Spam-Level:
X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, SPF_PASS=-0.001, 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 6hD3nUno+zXG; Tue, 30 Apr 2013 09:32:50 -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 BC5FE21F9ADF; Tue, 30 Apr 2013 09:32:49 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-99-236.dllstx.fios.verizon.net [173.57.99.236]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r3UGWnxl042939 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Tue, 30 Apr 2013 11:32:49 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Message-ID: <517FF231.3080700@nostrum.com>
Date: Tue, 30 Apr 2013 11:32:49 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "renum@ietf.org" <renum@ietf.org>, draft-ietf-6renum-gap-analysis@tools.ietf.org
References: <5159F239.1060001@nostrum.com>
In-Reply-To: <5159F239.1060001@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.57.99.236 is authenticated by a trusted mechanism)
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [renum] Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 16:32:50 -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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6renum-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10, 2013 IESG Telechat date: May 16, 2013 Summary: Ready with nits (that border on minor issues) This update improved the readability significantly, and addressed my major concern about being able to build a list of the gaps. Thank you. There are a few issues from my last call review that are still not addressed. I have left the classification of minor issue vs nits the same as the original review to make referring to the earlier review easier, but please consider all of these Nits. The IESG will need to decide whether to escalate them. I've trimmed away the points that were addressed. On 4/1/13 3:46 PM, Robert Sparks wrote: > ---------------------- > Minor issues: > > The document currently references > draft-chown-v6ops-renumber-thinkabout several times. > That document is long expired (2006). It would be better to simply > restate what is > important from that document here and reference it only once in the > acknowlegements > rather than send the reader off to read it. This version still references that long expired draft. There was also conversation on apps-discuss about making that reference normative. IMHO, this is not the right way to treat the RFC series, and strongly encourage moving the text that you want to reference into something that will become an RFC. > > > Should section 8 belong to some other document? It looks like > operational renumbering > advice/considerations, but doesn't seem to be exploring renumbering > gaps, except for > the very short section 8.2 which says "we need a better mechanism" > without much explanation. Afaict, this wasn't addressed at all. In particular, "we need a better mechanism" is still all that section 8.2 says. > > Section 5.1, first bullet. The list below "the impact of ambiguous M/O > flags" says things like > "there is no standard" and "it is unspecified". I think you are trying > to say that there is > ambiguity in what's written, not that nothing's written. This entire > list would benefit from > being recast in terms of what needs to be done (what are the gaps?). This text remains unmodified. > > ---------------------- > Nits/editorial comments: > > There are a few sentences ending with "etc." in the document. Please > consider deleting the > word from the list - it doesn't help each sentence make its point. There were some changes, but mostly these still exist. I'll leave pressing this point further to the RFC Editor. > > > Seciton 7.1: The first bullet does not parse. If I guess its meaning > correctly > (that it would be benificial to tell hosts that local DNS has been > updated and > they may want to make fresh queries), please be careful with the > wording. The > hosts don't know which names are likely to resolve locally. This text remained unchanged, and when coming back to the document for a re-review (which is somewhat like coming back to an RFC you've read before just for reference), it's even harder to understand what it's trying to say than it was when reading the document linearly. I think you are trying to say "A notification mechanism may be needed to indicate _to_ hosts that a renumbering event has _changed how local recursive DNS servers will respond_. That mechanism may also need to indicate that such a change will happen at a specific time in the future." > > Section 7.1, third bullet - This isn't obviously about notification. > Why is it > in this section? What's the gap this is trying to identify? This text was unchanged. > > Section 9.4 - what is it about these that make them gaps, much less > unsolvable gaps. > Is this discussion in the wrong section of the document? This is now section 10.3 and is mostly unchanged. It's still not clear why this discussion is in the "unsolvable gaps" section.
- [renum] Fwd: [Gen-art] Gen-art review: draft-ietf… Robert Sparks
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… Liubing (Leo)
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… Brian E Carpenter
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… Liubing (Leo)
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… Stig Venaas
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… Robert Sparks
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… joel jaeggli
- [renum] Gen-art telechat review: draft-ietf-6renu… Robert Sparks
- Re: [renum] Gen-art telechat review: draft-ietf-6… Liubing (Leo)
- Re: [renum] Gen-art review: draft-ietf-6renum-gap… Tim Chown
- Re: [renum] Gen-art telechat review: draft-ietf-6… Robert Sparks
- Re: [renum] Gen-art telechat review: draft-ietf-6… Stig Venaas
- Re: [renum] Gen-art telechat review: draft-ietf-6… Brian E Carpenter
- Re: [renum] Gen-art telechat review: draft-ietf-6… Liubing (Leo)
- Re: [renum] Gen-art telechat review: draft-ietf-6… Tim Chown
- Re: [renum] [Gen-art] Gen-art telechat review: dr… Jari Arkko
- Re: [renum] [Gen-art] Gen-art telechat review: dr… Stig Venaas