Re: [Gen-art] Gen-ART LC Review of draft-ietf-6man-dns-options-bis-03
2010-06-29 12:13:37
Ben,
The last paragraph can be written to clarify your question:
However, it is RECOMMENDED that at least three RDNSS addresses (or
DNSSL domain names) can be stored from at least two different
sources.
That is, the total number is three for RDNSS addresses (or DNSSL domain names).
I believe that I can submit the 04 version.
Thanks.
Best Regards,
Paul
On Mon, Jun 28, 2010 at 5:10 PM, Ben Campbell <ben(_at_)nostrum(_dot_)com>
wrote:
Hi,
Looking at the update:
Section 5.3.1, last two paragraphs:
I think the text is saying the right thing, but it seems a bit rushed could
use another round of word-smithing.
In the last paragraph, when you say, "However, it is RECOMMENDED that at
least three sets of addresses and
domain names can be stored from at least two different sources.", do you
mean 3 sets from each of 2 sources(i.e. 6 sets), or 3 sets total across two
sources?
Also, see my response to Jari concerning the last paragraph.
Otherwise, I think this version has addressed the rest of my comments.
Thanks!
Ben.
On Jun 26, 2010, at 10:19 PM, Jaehoon Paul Jeong wrote:
Ben,
I revised the I-D according to your follow-up comments as below:
The revised I-D is located at the following link:
http://www-users.cs.umn.edu/~jjeong/publications/ietf-internet-draft/draft-ietf-6man-dns-options-bis-04.txt
The difference between 03-version and 04-version is located:
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
On Fri, Jun 25, 2010 at 4:02 PM, Ben Campbell <ben(_at_)nostrum(_dot_)com>
wrote:
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(_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.
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?
According to Jari's comments and text, the new text 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 SHOULD keep
some DNS options from all sources. Unless explicitly specified for
the discovery mechanism, the exact number of addresses and domain
names to keep is a matter of local policy and implementation choice.
However, it is RECOMMENDED that at least three sets of addresses and
domain names can be stored from at least two different sources. The
DNS options from Router Advertisements and DHCP SHOULD be stored into
DNS Repository and Resolver Repository so that information from DHCP
appears there first and therefore takes precedence.
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
The new text is as follows:
However, it is RECOMMENDED that at least three sets of addresses and
domain names can be stored from at least two different sources.
--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.
To clarify this question, the following text is suggested:
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. As an
exceptional case, if the received RDNSS addresses (or DNS search
domain names) already exist in the IPv6 host, their Lifetime fields
update their expiration time, that is, when the corresponding DNS
information expires in the IPv6 host; note that when the Lifetime
field has zero, the corresponding RDNSS (or DNS search domain name)
is deleted from the IPv6 host. Except for this update, the IPv6 host
SHOULD ignore other RDNSS addresses (or DNS search domain names)
within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
DNSSL) options within an RA. Refer to Section 6 for the detailed
procedure. 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.
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.
[...]
The current 04-version has no such issues.
-- 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
--
Could you confirm whether this update is fine with you?
Thanks.
Best Regards,
Paul
_______________________________________________
Gen-art mailing list
Gen-art(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/gen-art
--
===========================
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
|
|