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.
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.
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.
----------------------
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.
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."
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.
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.