Draft:  draft-jeong-dnsop-ipv6-dns-discovery-08.tx t
Reviewer: Gray, Eric [Eric.Gray@marconi.com]
Review Date: Tuesday 6/27/2006 11:05 AM CST
IETF LC Date: 7/17/2006

Summary: This document does not appear to be quite ready for publishing as an 
Experimental RFC at this time.  

I have included below several comments and questions that should be 
resolved or clarified.


Comments:
========

In the last sentence of section 1.1, I cannot be certain I am parsing
this correctly as it is now.  Here is what I believe you are saying:

"Using the lifetime field differentiates the RA approach
 from the DHCPv6 approach in that it allows mobile nodes 
 to use local RDNSSes rather than remote RDNSSes in order 
 to reduce the DNS resolution delay [6]-[8]."
----------------------------------------------------------------------

In section 3, you define "Recursive DNS Server (RDNSS)" in terms of
a "recursive DNS resolution service".  I believe this is a well-known
concept in this domain of interest, but it would be helpful if you 
would also define what you mean by this, or point to somewhere where
it is defined.

The term is not defined in your references [4] and [5] (though many
more fundamental terms - such as "IP" - are).
----------------------------------------------------------------------

I am having some difficulty in figuring out what it means to have a
"hysteresis" delta in the values of the "PREF" field of the RDNSS
option - i.e. - why the special values of 8 and 11 (or 8 through 11).

In particular, I am having difficulty in reconciling the fact that -
as this field is now defined - it is possible to have multiple PREF
values that are "equivalent" to (neither greater than or less than)
manually configured RDNSS values, yet are different from each other.

After a few times re-reading this, it appears that you want to have
the values 8-11 reserved for manually configured RDNSS PREF values.
Then, it is possible to choose multiple values for RDNSS PREF in a
RDNSS option that are guaranteed to be higher than, or lower than,
any manually configured RDNSS PREF values.

This is somewhat murky in the current text.  How is this enforced?
What happens if an RDNSS is manually configured with a PREF of 15,
or 1?  Are manually configured RDNSS values restricted to values 
in this range (by - for instance - having a 2-bit field for PREF)?

The document should probably contain a little bit more on why this
is defined this way.  Minimally, it should clearly state intentions
with respect to limiting use of these values as appropriate (i.e. -
liberal use of "normative" declaration "MUST" and "MUST NOT").
----------------------------------------------------------------------

I am not certain I agree with the sense of section 7 as a whole
and - in particular - the second sentence.

The Security Considerations section appears to equate the RA 
option to ND in general and then to go into details of general 
security issues with ND.  It also explicitly claims (twice) 
that there is no new vulnerability.

I believe there is a new exposure associated with this proposal
as it appears to be intended to define a means to "prefer" a
specific RDNSS based on a PREF value and inferred locality.

In addition to the possibility of setting a higher preference
value in a spoofed message, it is also possible to defeat the
"locality" using an RDNSS option with an infinite lifetime.

While I am reasonably certain that current ND security handles
these issues, it seems to me that they should still be listed.
----------------------------------------------------------------------

I don't understand the note in section 8 (IANA Considerations).

It is not the usual case that this section is removed from an
RFC at the time of publishing.  Perhaps this simply needs to
be re-worded?
----------------------------------------------------------------------


NITs:
====

In section 3, I believe the first sentence might be better worded as:

"This document uses terminology defined in [4] and [5]."

----------------------------------------------------------------------

In section 4, the first sentence of the second paragraph would be 
slightly more readable if the references ([4] and [5]) were in
parentheses.

Also, in the fourth (last) paragraph (first sentence), "of RDNSS 
option" should be "of the RDNSS option" ("RDNSS option" is a term 
that has not been defined at this point in the document).

Alternatively, you could define "RDNSS option" in the terminology
section, or put quotes around it in this instance.

----------------------------------------------------------------------

In section 5.1, on page 6, under "Lifetime" - the second sentence
should read something like this:

"The maximum time, in seconds (relative to the time the packet is 
sent), over which this RDNSS MAY be used for name resolution."

----------------------------------------------------------------------

In section 7, second paragraph, near the end of the paragraph - 
"administatively" should be "administratively".

----------------------------------------------------------------------