ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-ietf-6man-dns-options-bis-03

2010-06-28 10:34:04
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?



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(_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