Re: [renum] Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)
"Liubing (Leo)" <leo.liubing@huawei.com> Mon, 13 May 2013 01:59 UTC
Return-Path: <leo.liubing@huawei.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 EC19521F8D41; Sun, 12 May 2013 18:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ODqeG74CbjmY; Sun, 12 May 2013 18:59:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A94E921F8464; Sun, 12 May 2013 18:59:04 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARH79014; Mon, 13 May 2013 01:59:03 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 02:58:45 +0100
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 13 May 2013 02:59:02 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.102]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Mon, 13 May 2013 09:58:59 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Robert Sparks <rjsparks@nostrum.com>
Thread-Topic: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)
Thread-Index: AQHOTZDVCx2KD3Z6N0mmZwguV2SXypkCXtWQ
Date: Mon, 13 May 2013 01:58:59 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D70E78D@nkgeml506-mbx.china.huawei.com>
References: <5159F239.1060001@nostrum.com> <517FF231.3080700@nostrum.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D700926@nkgeml506-mbx.china.huawei.com> <518D0E64.6020504@nostrum.com>
In-Reply-To: <518D0E64.6020504@nostrum.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.161]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "renum@ietf.org" <renum@ietf.org>, "draft-ietf-6renum-gap-analysis@tools.ietf.org" <draft-ietf-6renum-gap-analysis@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
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 01:59:10 -0000
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>. > >> > >> 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
- [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