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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf