Yes, thanks all - I think we're nearly there… Tim
On 13 May 2013, at 02:58, Liubing (Leo) <leo.liub...@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:rjspa...@nostrum.com] >> Sent: Friday, May 10, 2013 11:13 PM >> To: Liubing (Leo) >> Cc: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org; >> gen-...@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:rjspa...@nostrum.com] >>>> Sent: Wednesday, May 01, 2013 12:33 AM >>>> To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org >>>> Cc: gen-...@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 >
