Subject: [Gen-art] RE: Gen-ART Review (LC) of draft-jeong-dnsop-ipv6-dns-discovery-0 8.txt

From: "Gray, Eric" <[email-masked]>
Date: Fri, 6 Oct 2006 12:42:09 -0400

I noticed that a new version ("-09") has been submitted to the ID
repository, and I don't recall having closed the loop on this.  I
see that this happened about 2 months ago, and I have only just
become aware of it.

Based on the below response from Jaehoon and my reading of the
current version of the draft, I believe all of my issues have
been addressed.

There is one remaining NIT in the security section which can be
addressed as an RFC Editor note: 

	the phrase "is presumably and easier" most likely was meant
	to read "is presumably an easier" 

Otherwise, I believe this draft is ready for publishing as an
Experimental RFC.

--
Eric

--> -----Original Message-----
--> From: Jaehoon Jeong [mailto:[email-masked]] 
--> Sent: Tuesday, June 27, 2006 6:53 PM
--> To: 'Gray, Eric'; 'Jaehoon Paul Jeong'; 'Soohong Daniel 
--> Park'; 'Luc Beloeil'; 'Syam Madanapalli'
--> Cc: [email-masked]; 'Mark Townsley'; [email-masked]
--> Subject: RE: Gen-ART Review (LC) of 
--> draft-jeong-dnsop-ipv6-dns-discovery-08.txt
--> 
--> Hi Eric,
--> 
--> First of all, I appreciate your efforts on the review of our draft.
--> There are my answers on your comments inline.
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:[email-masked]]
--> > Sent: Tuesday, June 27, 2006 11:05 AM
--> > To: Jaehoon Paul Jeong; Soohong Daniel Park; Luc Beloeil; 
--> Syam Madanapalli
--> > Cc: [email-masked]; Mark Townsley
--> > Subject: Gen-ART Review (LC) of
--> draft-jeong-dnsop-ipv6-dns-discovery-08.txt
--> > 
--> > 
--> > I am the assigned Gen-ART reviewer for:
--> > 
--> > 	draft-jeong-dnsop-ipv6-dns-discovery-08.txt
--> > 
--> > For background on Gen-ART, please see the FAQ at
--> > <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
--> > 
--> > Please resolve these comments along with any other Last 
--> Call comments
--> > you may receive.
--> > 
--> > 
--> ------------------------------------------------------------
--> ---------
--> > 
--> > 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]."
--> 
--> Exactly.
--> 
--> > 
--> ------------------------------------------------------------
--> ----------
--> > 
--> > 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 try to clarify the definition of RDNSS as follows:
--> 
--> o  Recursive DNS Server (RDNSS): Server which provides a recursive
-->    DNS resolution service for translating domain names into IP
-->    addresses [RFC1034][RFC1034].
--> 
-->   * RFC1034 and RFC1035 will be replaced with reference numbers.
--> 
--> > 
--> ------------------------------------------------------------
--> ----------
--> > 
--> > 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).
--> > 
--> 
--> This default setting is similar to DHCPv6 convention.
--> For instance, manually configured and DHCPv6-derived DNS 
--> resolvers could
--> have a preference in the 8-11 range (0b10xx) so presumably, 
--> a preference of
--> < 8 means  
--> less preferred than manual or DHCPv6 while > 11 means more 
--> preferred.
--> 
--> I would like to suggest the following text with the purpose 
--> of this field
--> and enforcement for default value for manually configured RDNSSes:
--> 
-->      Pref          The preference of an RDNSS.  A 4-bit unsigned
-->                    integer.  Preference field allows IPv6 hosts
-->                    to select a primary RDNSS among several RDNSSes
-->                    available locally.  A decimal value of 15
-->                    indicates the highest preference.  A value of
-->                    zero means unspecified.  The default value of
-->                    preference MUST be from 8 to 11 for manually
-->                    configured RDNSSes.  A preference less than 8
-->                    means less preferred than manual configured
-->                    RDNSS and a preference greater than 11 means
-->                    more preferred.
--> 
--> Is this text fine with you?
--> 
--> > 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.
--> > 
--> 
--> I don't believe that the preference field introduces 
--> another security
--> problem.
--> The RDNSSes available locally are preferred to reduce the 
--> resolution delay.
--> If the RDNSS with high preference value cannot serve the 
--> DNS resolution
--> service, it is ignored by the IPv6 host.
--> 
--> 
--> > 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.
--> > 
--> 
--> When RA Router Lifetime expires, the RDNSS with infinite 
--> lifetime for RDNSS
--> is deleted in the case where S flag is set off. Please 
--> refer to NOTE in
--> Section 6.1 (DNS Server List Management).
--> 
--> The RDNSS with S flag on is used as a last resort, that is, 
--> regarded as the
--> lowest in preference regardless of the RDNSS lifetime. 
--> So, there is no problem if the ND security is provided.
--> 
--> > 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?
--> 
--> Okay, how about the following text?
--> 
--> 8.  IANA Considerations
--> 
-->    The IANA assigns a new IPv6 Neighbor Discovery Option 
--> type for the
-->    RDNSS option defined in this document.
--> 
-->                  Option Name               Type
-->                  RDNSS option              (TBD)
--> 
--> > 
--> ------------------------------------------------------------
--> ----------
--> > 
--> > 
--> > 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".
--> > 
--> > 
--> ------------------------------------------------------------
--> ----------
--> 
--> For the NITs, I will correct your comments.
--> 
--> Thanks.
--> 
--> Jaehoon
--> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: [email-masked]
Date: 06 Oct 2006 15:56:53 -0500

Hi Eric,

I appreciate your efforts.

Actually, there was an IESG telechat meeting about one month ago.
There are several comments on the current version.
After reflecting these comments along with your comments below,
the authors including me will submit the new version.

Thanks.

Jaehoon