Resending to the list with the source address that appears to be
expected (the original message seems to have been filtered)...
This time I'm also copying the ipv6 list. In fact, [EMAIL PROTECTED] would be
more suitable place for discussions on this proposal, since it's an
extension to ND.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Mon, 19 Jun 2006 19:47:07 -0400,
>>>>> The IESG <[EMAIL PROTECTED]> said:
> The IESG has received a request from an individual submitter to consider the
> following document:
> - 'IPv6 Router Advertisement Option for DNS Configuration '
> <draft-jeong-dnsop-ipv6-dns-discovery-08.txt> as an Experimental RFC
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-17.
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery-08.txt
I have several comments on this draft:
- A meta level comment
I'm afraid I'm re-raising an old discussion (in which case I hope
someone will point it out), but I'm concerned that this document may
open up a possibility of making (autoconfiguration via) Router
Advertisement a convenient and uncontrollable kitchen sink. In my
understanding, the applicability of RA in the original design was
limited to a minimum number of layer-3 configuration information
parameters, such as subnet prefixes and default router addresses.
If my understanding is correct and the design principle still
applies, the proposed option is (IMO) against the principle because
the configuration information provided by this document (i.e.,
recursive DNS server addresses) is (again IMO) at a far higher layer
than the intended one. And the standardization of this option will
then be used as an excuse for succeeding violation like "XXX server
address ND option" for arbitrary "XXX" protocols.
So,
+ I'd first like to confirm whether my understanding about the
'design principle' is correct. If it's wrong, then I'm fine and
this concern will be resolved.
+ if my understanding is correct, I'd like this document to discuss
why this particular option is so special and needs to be defined
despite the violation of the principle, and to add an explicit
note that configuration information around this layer should not
be provided via RA unless there is a very strong reason.
- other non editorial comments
1. (in section 1.1)
> Using the lifetime field differentiate RA approach
> from DHCPv6 approach in that it allows mobile nodes to use local
> RDNSSes rather than remote RDNSSes in order to being able to reduce
> the DNS resolution delay [6]-[8].
I don't think this is true. It seems to me that the DHCPv6 approach
can provide the same thing (at least in this context) by means of the
Information Refresh Time Option. If this statement tries to say the
lifetime field can provide something more, it should be explicitly
explained.
2. (in section 4)
> The preference field of RDNSS option allows IPv6 hosts to select a
> primary RDNSS among several RDNSSes; this can be used for load
> balancing of RDNSSes.
I don't see how the preference field helps load-balancing. Perhaps it
assumes load-balancing by differentiating RRDNS preferences for
different RAs? If so, I suspect it's not effective, but in any case I
think it's non trivial and should be explained explicitly.
3. (in section 5.1, about the "S" flag)
> This flag
> SHOULD be set only if the routers or firewalls in
> the network allow DNS Query messages to be routed
> to the destination RDNSS without being filtered
> out, and the RDNSS is configured to perform
> recursive queries for all hosts regardless of
> their addresses.
My understanding is that current operational trend is generally
against such "open recursive servers" as documented in
draft-ietf-dnsop-reflectors-are-evil-00.txt. So I'm skeptical about
the usefulness of this flag. Standardizing such a practice may even
be regarded as a conflict with the operational trend.
I don't have a strong opinion by pointing it out, but I might consider
removing this flag.
4. (in Section 8)
> Note
> This section will be removed after the assignment of RDNSS option
> type.
Is this correct? I'd rather expect the IANA considerations section
will have the assigned option type number (if this option is ever
approved, of course).
- editorial comments
5. (in Section 1.1)
> (e.g., 3GPP), MIPv6 (especially, HMIPv6), NEMO and MANET connected to
I'd add (informational) references for MIPv6, HMIPv6, NEMO, and MANET.
6. (in Section 1.1)
> Especially, the new RA option may be useful in some
> mobile environments where the addresses of the RDNSSes are added or
> deleted according to a mobile node's movement because the RA option
> includes a lifetime field that allows the mobile node to delete the
> expired entries for RDNSSes.
It's not reasonable to see the acronym "RDNSS" is used before the
definition (in Section 3). The full term should be used or given with
the acronym.
7. (in Section 1.1)
> This lifetime field can be configured
> to a value that will require the mobile node to time out the RDNSS
> address entry in the previous network and to switch over to another
> RDNSS address in the same network.
"the same network" sounds confusing to me. Is this the "previous
network", or some different network after movement? I guess it's the
latter from the context, and if so, I'd say e.g., "the current
network" or "a new network".
8. (in Section 6.1)
> Any least recently used (LRU)
> policy that reclaims entries that have expired with Service-open-
> flag set to 0 can be adopted for replacing the expired entries
> with the entries for newly announced RDNSSes [4].
I don't understand why "[4]" (RFC2461) is referred to here.
9. (in Section 6.1)
> When the S flag is set, the RDNSS may continue to be used
> after either or both of these lifetimes have expired and there are
> not any more eligible RDNSSes (with still valid lifetimes or learned
> through DHCP or manual configuration) are available [6]-[8].
two issues:
- the phrase after "and there are..." is not grammatically parsable.
Maybe remove the second "are"?
- I think the position of the references to [6]-[8] is rather
confusing. I'd rather remove them, or move them just after "DHCP".
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- End Message ---
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
