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 PROTECTED] > Sent: Tuesday, June 27, 2006 11:05 AM > To: Jaehoon Paul Jeong; Soohong Daniel Park; Luc Beloeil; Syam Madanapalli > Cc: [email protected]; 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 protected] https://www1.ietf.org/mailman/listinfo/gen-art
