Draft:  draft-ietf-dnsop-ipv6-dns-issues-10
Reviewer: Michael A. Patton [MAP@MAP-NE.com]
Date: Tuesday 6/7/2005 4:58 AM CST

Summary: This draft is basically ready for publication, but has nits that
	should be fixed before publication.

Review Comments:

In looking through the document, there was one thing that really
concerned me (see "Major concern"), but isn't really something
critical, just a concern about how fast it can become an RFC.  The
fact that the speed of publication concerns me SHOULD be taken as an
indication that I feel this is an important document to get
published.  I had a number of lesser comments, mostly suggestions for
places where some improvement could be made, but is not really
required.  I also listed a number of typos that I saw, I'm sure there
are more that I missed.


Major concern
-------------

My major concern is with the number of references that are still ID.
Are these IDs really close enough to completion?  Actually, in the
process of doing the review I had reason to want to refer to several
of the IDs for further info and crosschecking, all the ones that I
tried to look up were expired.  It's probably of enough importance to
get this draft out as an RFC that holding it up for another draft
still being revised would be unfortunate.  But even some of the
informative references are fairly important, so I'm not sure where to
go on this...


Minor comments
--------------

Just before the heading for section 1.1 there is a mention of
site-local addresses.  It should mention that they are deprecated
(which, presumably, is why the discussion has been relegated to an
Appendix), you could probably just steal the text used in 2.1.

The third paragraph of section 1.2 seems too wishy-washy to me.  I
think that you are saying not to make a distinction (and I agree with
that), but the way it's actually worded makes it look like you're
recommending making a distinction.  Except for that paragraph, you
always say the answer shouldn't depend on the protocol the query came
on, but this paragraph seems to recommend sifferent Additional
sections based on transport.  I think the wording of this paragraph
needs to be cleaned up to avoid that misperception.

I noticed you reference draft-ietf-dnsop-dontpublish-unreachable which
tends to be controversial whenever it's discussed, and is, in fact,
expired right now.  The only place it's referenced from doesn't really
need the reference, it's pretty obviously The Right Thing without the
added info in dontpublish (and doesn't really touch on the
controversial parts).  I think just deleting the reference is fine,
although maybe an additional sentence would help.

The two paragraphs in section 2.4 seem out of order since the first
references the second in the past tense.  After some consideration, I
think the structure here would work better by combining 2.3 and 2.4
together as a "2.3 Transition addresses" with some intro text about
the general plan (i.e. most of what's in 2.4 first paragraph), then
sections 2.3.1 and 2.3.2 for the two specific cases described (2.3.1
would just be the current 2.3 and 2.3.2 would be the second paragraph
of 2.4).  However, this is a sufficient change that you probably only
want to consider it if you are otherwise respinning the document
anyway.

Near the end of section 4.4.3 it talks about EDNS0 as a way to deal
with size issues in IPv6 data.  I thought there was somewhere a
requirement to implement EDNS0 that might have applied.  I was going
to recommend a reference, but I couldn't find it in a quick search, I
only found one referring to A6 records.  Perhaps I'm misremembering
this, maybe that's all there was.  I bet SRA would know for sure.

There were a large number of places where I found the text somewhat
tortuous to read and understand, but did eventually figure it out.
None of them were sufficient to cause an objection, but it might be
useful, if the document gets revised anyway, to have someone do a
language pass over it...but only if it's being redone as an ID anyway,
since this would add delay to publication that's not critical (and the
RFCed might be able to fix some of them anyway as a normal part of RFC
prep).


Typos
-----

The opening sentence of Section 4.1:
   It makes sense to keep logically separate services by a node separate
   in the DNS, due to a number of reasons, for example:
is not proper English (to my understanding).  It's sufficiently
mangled that I can't be sure what the intendedmeaning was, but I'd
suggest this replacement text as my best guess at a better wording:
   It makes sense to keep information about separate services
   logically separate in the DNS by using different DNS nodes.  There
   are several reasons for doing this, for example:
Although that still seems a bit stilted.


In Section 4.1: "in cases if some" => "in cases where some"

In Section 4.2: "could be either added" => "could either be added"

In Section 4.3: "important if the" => "important that the"

In Section 4.4.1: "conjunction of MX records is shown"
	     => "conjunction with MX records as shown"

In Section 4.4.2: "and a causing a protocol" => "and causing a protocol"

In Section 4.5: Either both critical and courtesy should be quoted, or
		neither should be.

In Section 4.5: "should be still aware" => "should still be aware"

In Section 6: "While the topic how to enable"
	   => "While the topic of how to enable"

In Section 7.1: "IP address to the reverse DNS"
	     => "IP address in the reverse DNS"

In Section 7.3: "unfeasible" => "infeasible"

In Section 10: "To re-emphasize which was" => "To re-emphasize what was"