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@xxxxxxxxxxx] > Sent: Friday, May 10, 2013 11:13 PM > To: Liubing (Leo) > Cc: renum@xxxxxxxx; draft-ietf-6renum-gap-analysis@xxxxxxxxxxxxxx; > gen-art@xxxxxxxx; ietf@xxxxxxxx > 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@xxxxxxxxxxx] > >> Sent: Wednesday, May 01, 2013 12:33 AM > >> To: renum@xxxxxxxx; draft-ietf-6renum-gap-analysis@xxxxxxxxxxxxxx > >> Cc: gen-art@xxxxxxxx; ietf@xxxxxxxx > >> 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