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