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(_at_)nostrum(_dot_)com]
Sent: Monday, June 21, 2010 5:08 PM
To: draft-ietf-6man-dns-options-bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
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.
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.
--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.
-- 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.
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
I added "the".
-- section 4, paragraph 1:"called DNSSL option"
_the_ DNSLL option
I added "the".
-- section 4, paragraph 2:"Existing ND message"
_The_ [or An] existing ND message ...
I added "The".
-- 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.
-- 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].
If I'm reading this right, it seems like the sentence repeats the same thing
twice.
-- 5.3.1, first paragraph: "follow:"
follows
I corrected it as 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.
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.
-- 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.
-- 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.
-- 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.
-- 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.
Could you confirm whether the revised I-D addressed all of your comments?
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(_dot_)paul(_at_)gmail(_dot_)com
URI: http://www.cs.umn.edu/~jjeong/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf