Re: [renum] Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

Tim Chown <tjc@ecs.soton.ac.uk> Mon, 13 May 2013 17:36 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
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 70C8B21F9360; Mon, 13 May 2013 10:36:52 -0700 (PDT)
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=[BAYES_00=-2.599]
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 yqWy7cKTAL7e; Mon, 13 May 2013 10:36:51 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id AF72221F92EC; Mon, 13 May 2013 10:36:50 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4DHaeb7002327; Mon, 13 May 2013 18:36:40 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r4DHaeb7002327
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1368466601; bh=2V0DYH5kp9U5ILMW21bt8kk2W2I=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=l9vEDQOez3IKjkJVvVEJcc75j6MNN0PxoUceAzPSypWWNGuG9SG21fh0mVrQrr9Tx 45hGi5VDDMWGDoB1F1wE29FIdtNrn194D5OOKyCdslLUzuwRk+896BeVot5GnqYuCb PT1MY9H+EPpNHH/Iiujaw3yL+sn11Tjxsli6UuT0=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id p4CIae0430602276Nl ret-id none; Mon, 13 May 2013 18:36:41 +0100
Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r4DHaVuD017767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 May 2013 18:36:32 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D70E78D@nkgeml506-mbx.china.huawei.com>
Date: Mon, 13 May 2013 18:36:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|fe2727486afbb9ad7009bcf9319d50dbp4CIae03tjc|ecs.soton.ac.uk|3D439D9C-E9FE-427C-9E35-8EC8468202F0@ecs.soton.ac.uk>
References: <5159F239.1060001@nostrum.com> <517FF231.3080700@nostrum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D700926@nkgeml506-mbx.china.huawei.com> <518D0E64.6020504@nostrum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D70E78D@nkgeml506-mbx.china.huawei.com> <3D439D9C-E9FE-427C-9E35-8EC8468202F0@ecs.soton.ac.uk>
To: Liubing (Leo) <leo.liubing@huawei.com>
X-Mailer: Apple Mail (2.1503)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=p4CIae043060227600; tid=p4CIae0430602276Nl; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: r4DHaeb7002327
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "renum@ietf.org" <renum@ietf.org>, "draft-ietf-6renum-gap-analysis@tools.ietf.org" <draft-ietf-6renum-gap-analysis@tools.ietf.org>, Robert Sparks <rjsparks@nostrum.com>
Subject: Re: [renum] Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)
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: Mon, 13 May 2013 17:36:52 -0000

Yes, thanks all - I think we're nearly there…

Tim

On 13 May 2013, at 02:58, Liubing (Leo) <leo.liubing@huawei.com> wrote:

> Hi, Robert
> 
> Your careful review and comments really helped improving the document a lot.
> Many thanks to you.
> 
> All the best,
> Bing
> 
>> -----Original Message-----
>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>> Sent: Friday, May 10, 2013 11:13 PM
>> To: Liubing (Leo)
>> Cc: renum@ietf.org; draft-ietf-6renum-gap-analysis@tools.ietf.org;
>> gen-art@ietf.org; ietf@ietf.org
>> Subject: Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
>> (updated for -07)
>> 
>> Thanks Bing -
>> 
>> The updates make the document better, and I appreciate the resolution of
>> referencing Tim's expired draft.
>> I think you've addressed all my comments except for the one on section
>> 5.1, but that's ok.
>> 
>> For completeness and ease on the ADs, here's an updated summary:
>> 
>> Document: draft-ietf-6renum-gap-analysis-05.txt
>> Reviewer: Robert Sparks
>> Review Date: May 10, 2013
>> IETF LC End Date: April 10, 2013
>> IESG Telechat date: May 16, 2013
>> 
>> Summary: Ready
>> 
>> 
>> 
>> On 5/2/13 6:02 AM, Liubing (Leo) wrote:
>>> Hi, Robert
>>> 
>>> Thanks a lot for your continuous careful review.
>>> Please see replies inline.
>>> 
>>>> -----Original Message-----
>>>> From: Robert Sparks [mailto:rjsparks@nostrum.com]
>>>> Sent: Wednesday, May 01, 2013 12:33 AM
>>>> To: renum@ietf.org; draft-ietf-6renum-gap-analysis@tools.ietf.org
>>>> Cc: gen-art@ietf.org; ietf@ietf.org
>>>> Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
>>>> 
>>>> 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>gt;.
>>>> 
>>>> 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.
>>> [Bing] Maybe Brian's suggestion of putting some texts into an appendix is a
>> good way. We'll discuss this problem when make the next time update.
>>> 
>>>>> 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.
>>> [Bing] Sorry for leaving it out. Will do in next update.
>>> 
>>>>> 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.
>>> [Bing] We made revision focusing on explaining "what are the gaps", but
>> the texts change was omitted, will do in next update.
>>> 
>>>>> ----------------------
>>>>> 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.
>>> [Bing] A professional language/editorial check would be helpful.
>>> 
>>>>> 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."
>>> [Bing] I think it's a better description. Will update, thanks much.
>>> 
>>>>> 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.
>>> [Bing] For example, if border routers enabled egress filtering based on the
>> SIP, then the router need to know the renumbering events on some internal
>> nodes. We'll make it clear in the next version.
>>> 
>>>>> 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.
>>> [Bing] We considered the two points (ID/Locator overloading in transport
>> layer & address caching in app layer ) are too fundamental that might not be
>> proper to modify them just in terms of renumbering.
>>> 
>>> Best regards,
>>> Bing
>