Subject: RE: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 2 May 2013 11:02:30 +0000

Hi, Robert

Thanks a lot for your continuous careful review.
Please see replies inline.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, May 01, 2013 12:33 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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

---

From: Tim Chown <[email-masked]>
Date: Mon, 6 May 2013 17:25:11 +0100

On 30 Apr 2013, at 16:43, joel jaeggli <[email-masked]> wrote:

> On 4/30/13 8:33 AM, Robert Sparks wrote:
>> On 4/2/13 4:58 AM, Brian E Carpenter wrote:
>>> Just picking a couple of points for further comment:
>>> 
>>> On 02/04/2013 08:46, Liubing (Leo) wrote:
>>>> 
>>>> [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap analysis. Although the draft is expired, most of the content are still valid.
>>>> draft-chown is a more comprehensive analysis, while the gap draft is focusing on gaps in enterprise renumbering. So it might not easy to abstract several points as important from draft-chown to this draft. We actually encourage people to read it.
>>> Robert is right, though, sending people to a long-expired draft is a bad idea.
> I'm not sure I see that as worse than referring to Wikipedia, an expired draft has the property that it's not going to change. I have no problem with the idea that it would be an informative reference.   but yes it's a bit much to say go read this.
>>> Of course we have to acknowledge it, but maybe we should pull some of its text
>>> into an Appendix.
>>> 
>>> Tim Chown, any opinion?
>> The most recent version (and the one slated for the next telechat) still has this long-expired draft referenced.

Hi,

The old renumbering "thinkabout" draft came out of experiments on IPv6 renumbering we did in 6NET some 10 (yikes!) years ago, for both enterprise and ISP networks. I think most of what was written is still applicable.  Brian borrowed a fair deal of it for RFC 5887.  I stopped work on it as there was little/no interest in the problem in v6ops at the time (or whatever v6ops was called back then). We produced technical 6NET reports separately, and did some follow-up work with Cisco separately.

Personally I don't mind if the principles are mentioned without the explicit reference - an ack in the Acknowledgements is adequate. 

It would be interesting to review the "thinkabout" draft to see how much still holds true.  Glancing at it, sections like "Application and Service-Oriented Issues" are still very much relevant. I guess Stig and I could consider advancing it along the Independent Submission path, or look for publication to an appropriate journal.  Life is short :)

Tim

---

From: Robert Sparks <[email-masked]>
Date: Fri, 10 May 2013 10:12:36 -0500

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 May 2013 07:35:12 +1200

On 11/05/2013 04:58, Stig Venaas wrote:
> On 5/10/2013 8:12 AM, Robert Sparks wrote:
>> Thanks Bing -
>>
> So the solution is to not reference it? I see the name of the draft is
> mentioned in the acknowledgments as:
>  [draft-chown-v6ops-renumber-thinkabout].
> 
> Shouldn't it then be an informational reference? It doesn't make sense
> to me to mention a draft in the text and not have a reference.

YMMV, but I expect the RFC Editor will resolve this.

   Brian

---

From: Stig Venaas <[email-masked]>
Date: Fri, 10 May 2013 09:58:16 -0700

Stig

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 13 May 2013 01:58:59 +0000

Hi, Robert

Your careful review and comments really helped improving the document a lot.
Many thanks to you.

All the best,
Bing

> Sent: Friday, May 10, 2013 11:13 PM
> To: Liubing (Leo)
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt
> (updated for -07)
> 
> Thanks Bing -
> 
> > [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.
> >
> > [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:
> >>>
> > [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.
> >
> > [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

---

From: Tim Chown <[email-masked]>
Date: Mon, 13 May 2013 18:36:31 +0100

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

Tim