Hi, thanks for the quick response. Followup comments inline: On Jun 24, 2010, at 6:13 PM, Jaehoon Paul Jeong wrote: > Hi Ben, > First of all, I sincerely appreciate your review work on our I-D. > I tried to address all of your comments with a revised version: > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt > > The difference between version 03-and version-04 can be found in > http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/wdiff%20draft-ietf-6man-dns-options-bis-03_txt%20draft-ietf-6man-dns-options-bis-04_txt.htm > > Also, I answered your comments inline as below: > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@xxxxxxxxxxx] >> Sent: Monday, June 21, 2010 5:08 PM >> To: draft-ietf-6man-dns-options-bis.all@xxxxxxxxxxxxxx >> Cc: General Area Review Team; IETF Discussion >> Subject: Gen-ART LC Review of draft-ietf-6man-dns-options-bis-03 >> >> 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 resolve these comments along with any other Last Call comments >> you may receive. >> >> Document: draft-ietf-6man-dns-options-bis-03 >> Reviewer: Ben Campbell >> Review Date: 2010-06-21 >> IETF LC End Date: 2010-06-23 >> IESG Telechat date: (if known) >> >> Summary: >> >> This draft is almost ready for publication as a proposed standard. However, there are some issues, both substantive and editorial, that should be considered prior to publication. >> >> Major issues: >> >> -- 5.3.1, last paragraph: >> "In the case where the DNS options of RDNSS and DNSSL can be obtained >> from multiple sources, such as RA and DHCP, the IPv6 host can keep >> some DNS options from RA and some from DHCP; for example, two RDNSS >> addresses (or DNS search domain names) from RA and one RDNSS address >> (or DNS search domain name) from DHCP." >> >> This seems underspecified. For example, can it choose the last value from each? How is the host to guess which to keep? How can an administrator get predictable behavior? Mixing some from one source and another from the second seems, on the surface, like the worst possible behavior. Since using RA for this was described as an alternative for when DHCPv6 was not available, wouldn't it make more sense for dhcp to win? >> >> Furthermore, this makes me wonder if the concept here needs more thought. Under what circumstance would you be both doing stateless autoconfig and getting DHCPv6 for the _same_ interface? >> > > The new text for these questions is as follows: > > In the case where the DNS options of RDNSS and DNSSL can be obtained > from multiple sources, such as RA and DHCP, the IPv6 host can keep > some DNS options from RA; the sufficient number of RDNSS addresses or > DNS search domain names is determined as a reasonable number (e.g., > three) by the local policy. On the other hand, for DHCP DNS options, > the DHCP configuration determines the number of DNS options > advertised to IPv6 hosts, so the sufficient number is out of scope in > this document. With these sufficient numbers of RDNSS addresses and > DNS search domain names, the DNS options from RA and DHCP are stored > into DNS Repository and Resolver Repository in the order that the > latest received RDNSS or DNSSL is most preferably used for DNS > queries. > > With this text, the sufficient number of RDNSS addresses in RA DNS > options is determined > according to the local policy, independent of DHCP. I'm still confused. Are we still talking about getting entries from both RA and DHCP on the same interface? Would this happen other than in error conditions? > >> >> Minor issues: >> >> -- 5.3.1, 2nd to last paragraph: "When the IPv6 host has gathered a sufficient number (e.g., three)" >> >> Can you provide guidance on what is reasonable sufficient? Did you mean 3 as a recommendation? >> > > The number of three is arguable, but the previous DNS work recommended > three for RDNSS addresses as follows: > http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 > > Also, I added the new text in Section 5.3.1 as follows: > > In this document, three is recommended as a > sufficient number considering both the robust DNS query and the > reasonably time-bounded recognition of the unreachability of DNS > servers. Okay, except you probably want a normative RECOMMENDED > >> --5.3.1, 2nd to last paragraph: "it MAY ignore additional RDNSS addresses (or DNS search domain names) within an >> RDNSS (or DNSSL) option and/or additional RDNSS (or DNSSL) options within an RA." >> >> How does this interact with lifetimes? This seems a little underespecified. >> > > The new text for this comment is as follows: > > When the IPv6 host has gathered a sufficient number (e.g., three) of > RDNSS addresses (or DNS search domain names), it SHOULD maintain > RDNSS addresses (or DNS search domain names) by the sufficient number > such that the latest received RDNSS or DNSSL is more preferred to the > old ones; that is, when the number of RDNSS addresses (or DNS search > domain names) is already the sufficient number, the new one replaces > the old one that will expire first in terms of Lifetime. In this > case, the IPv6 host SHOULD ignore additional RDNSS addresses (or DNS > search domain names) within an RDNSS (or DNSSL) option and/or > additional RDNSS (or DNSSL) options within an RA. Note that the > sufficient number is a system parameter, so it can be determined by a > local policy. Also, separate parameters can be specified for the > sufficient number of RDNSS addresses and that of DNS search domain > names, respectively. In this document, three is recommended as a > sufficient number considering both the robust DNS query and the > reasonably time-bounded recognition of the unreachability of DNS > servers. I'm still confused. I read this to say that, once I reach the "sufficient" number of entries, any new entry should replace the oldest existing one, but then it goes on to say that if I have enough entries I should ignore new ones? Also, when ignoring entries, one must at least make sure the ignored entry does not match an existing entry and set the lifetime to zero, right? Otherwise, you may be ignoring a request to delete an entry. > >> -- 6.2, 2nd to last paragraph: "Note that, in the case where there are several routers advertising RDNSS option(s) in a subnet, the RDNSSes that have been announced recently are preferred." >> >> Can you elaborate on why this is the case? >> > > I deleted this sentence because our DNS options can work regardless of > the number of routers advertising > RA DNS options in a subnet. Okay. > >> Nits/editorial comments: >> >> -- General >> Idnits reports some lines over 72 characters. Please check. >> > > I checked Idnits. There is no issue. > >> -- Section 4, paragraph 1: "option called RDNSS option" >> >> _the_ RDNSS option Do you mean no issue for 03, or on the new version? idnits still shows the following on 03: (See http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-6man-dns-options-bis-03.txt ) > Checking nits according to http://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > ** There are 4 instances of too long lines in the document, the longest one > being 51 characters in excess of 72. > > [...] > >> -- Section 5.1, Field Type :"8-bit identifier of the RDNSS option type as assigned by the IANA: 25" >> >> Has IANA already assigned 25, or is this a recommendation? Why is there a number here but TBD in the other field type? > > As the revised I-D, RDNSS option is assigned an option type in RFC > 5006, but DNSSL option needs another option type. > Okay, that make sense as long as IANA understands what is meant. >> >> -- Section 5.1, Lifetime: "the value of Lifetime should be at least as long as the Maximum RA Interval (MaxRtrAdvInterval) in [RFC4861], and be at SHOULD be bounded as follows: MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval." >> > > The new text is as follows: > > the value of Lifetime SHOULD be bounded as MaxRtrAdvInterval <= > Lifetime <= 2*MaxRtrAdvInterval where MaxRtrAdvInterval is > the Maximum RA Interval defined in [RFC4861]. Okay. [...] > >> -- 5.3.1, first two bullets: >> >> This is confusing to me due to the way the determination of validity and actions to take if it is valid or invalid are intertwined. It would be better to first state how to determine validity, then say what actions to take if it is valid or invalid. >> >> > > The new text is organized according to this comment as follows: > > When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL > option) through RA messages, it processes the options as follows: > > o The validity of DNS options is checked with the Length field; that > is, the value of the Length field in the RDNSS option is greater > than or equal to the minimum value (3) and also the value of the > Length field in the DNSSL option is greater than or equal to the > minimum value (2). > > o If the DNS options are valid, the host SHOULD copy the values of > the options into the DNS Repository and the Resolver Repository in > order. Otherwise, the host MUST discard the options. Okay, that helps. > >> >> -- 6.2, 2nd paragraph (Step a): "Note that Step (e) is performed whenever an entry expires in the >> DNS Server List." >> >> It seems like step (e) doesn't belong in the list, since the rest of e list is triggered by receiving an RA. That is, it's not part of the same sequence of actions as the rest of the list. > > The new text is to reflect this comment as follows: > > The handling of expired RDNSSes is as follows: Whenever an entry > expires in the DNS Server List, the expired entry is deleted from the > DNS Server List, and also the RDNSS address corresponding to the > entry is deleted from the Resolver Repository. Okay. > >> >> -- 6.2, 2nd to last paragraph: "In the order in the RDNSS option, position the newly added RDNSS addresses in front of >> the Resolver Repository so that the new RDNSS addresses may be name resolution." >> >> The sentence is hard to parse. Are the two mentions of RDNSS order redundant? >> > > The new text is as follows: > > For the ordering of RDNSS addresses in an RDNSS > option, position the first RDNSS address in the RDNSS option as > the first one in the Resolver Repository, the second RDNSS address > in the option as the second one in the repository, and so on. > This ordering allows the RDNSS addresses in the RDNSS option to be > preferred according to their order in the RDNSS option for the DNS > name resolution. > Okay. >> -- 6.3, 2nd paragraph: "Note that Step (e) is performed whenever an entry expires in >> the DNS Search List." >> >> It seems like step (e) doesn't belong in the list, since the rest of e list is triggered by receiving an RA. That is, it's not part of the same sequence of actions as the rest of the list. >> > > The new text is as follows: > > The handling of expired DNSSLs is as follows: Whenever an entry > expires in the DNS Search List, the expired entry is deleted from > the DNS Search List, and also the DNSSL domain name corresponding > to the entry is deleted from the Resolver Repository. Okay > >> -- 7, first paragraph: "It can be claimed that the..." >> >> So are you asserting that claim, or just mentioning that you could? (Pattern repeats at least one more time further down.) >> > > The new text is as follows: > > Thus, the vulnerability of ND is not worse and is a subset of the > attacks that any node attached to > a LAN can do independently of ND. Okay > > > Could you confirm whether the revised I-D addressed all of your comments? I think it addresses all of my comments except when I explicitly mentioned otherwise above. (That is, I believe anything I responded with as "okay" and anything I deleted without response to be addressed.) > > Once I get your confirmation, I will submit this revised I-D to IETF. > > Thanks. > > Best Regards, > Paul > -- > =========================== > Paul (Jaehoon) Jeong > Software Engineer, Ph.D > Brocade > 6000 Nathan Ln N, Plymouth, MN 55442 > Mobile: +1.651.587.7774 > Email: jaehoon.paul@xxxxxxxxx > URI: http://www.cs.umn.edu/~jjeong/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf