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

[Tim Chown <[e-mail]>]

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

Tim

On 13 May 2013, at 02:58, Liubing (Leo) <[e-mail]> 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:[e-mail]]
>> Sent: Friday, May 10, 2013 11:13 PM
>> To: Liubing (Leo)
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> 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:[e-mail]]
>>>> Sent: Wednesday, May 01, 2013 12:33 AM
>>>> To: [e-mail]; [e-mail]
>>>> Cc: [e-mail]; [e-mail]
>>>> 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
>