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

2013-05-13 Thread Stig Venaas

On 5/10/2013 8:12 AM, Robert Sparks wrote:

Thanks Bing -

The updates make the document better, and I appreciate the resolution of
referencing Tim's expired draft.


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.

Stig



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

2013-05-13 Thread Liubing (Leo)
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

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

2013-05-13 Thread Tim Chown
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

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

2013-05-10 Thread Robert Sparks

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 

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

2013-05-10 Thread Brian E Carpenter
On 11/05/2013 04:58, Stig Venaas wrote:
 On 5/10/2013 8:12 AM, Robert Sparks wrote:
 Thanks Bing -

 The updates make the document better, and I appreciate the resolution of
 referencing Tim's expired draft.
 
 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