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? 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? --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. -- 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? Nits/editorial comments: -- General Idnits reports some lines over 72 characters. Please check. -- Section 4, paragraph 1: "option called RDNSS option" _the_ RDNSS option -- section 4, paragraph 1:"called DNSSL option" _the_ DNSLL option -- section 4, paragraph 2:"Existing ND message" _The_ [or An] existing ND message ... -- 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? -- 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." If I'm reading this right, it seems like the sentence repeats the same thing twice. -- 5.3.1, first paragraph: "follow:" follows -- 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. -- 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. -- 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? -- 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. -- 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.) _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf