(trying to resend from a different address which I guess the list
management system expects)
I've also added a few more comments to the previous (undelivered)
message. So if the original message is ever delivered, please just
ignore it (and forgive me for the duplicate).
>>>>> On Wed, 16 Jun 2004 13:21:11 -0700,
>>>>> David Meyer <[EMAIL PROTECTED]> said:
> Please review the document carefully, and send your
> feedback to the list. Please also indicate whether or
> not you believe that this document is ready to go to the
> IESG. Note that this is a somewhat unusal case as the
> IESG requested this document.
Comments are below.
In short, I don't think it's ready to be sent to the IESG. I agree
this can be a useful document, but it still contains non trivial
issues.
A meta comment (question):
This draft seems to adopt all the three approaches. Does this mean we
gave up on choosing a single particular approach for this purpose, or
even gave up on specifying one "default" approach? If so, then I
guess implementors will need to implement all the approaches (if it
needs implementation support) and/or operators will need to be
familiar with all possible approaches. Is my understanding correct?
See also a specific comment 11 below.
Then...I'm sad. With the chaos we've seen so far on this, however, I
understand what we need is some kind of compromise to move forward,
and I guess this is perhaps the compromise.
NON EDITORIAL COMMENTS (some of them may still be minor though)
1. Author list
Currently eight people are listed, which are much more than the norm
(up to 5) mentioned in Section 2.12 of
draft-rfc-editor-rfc2223bis-07.txt
2. formfeed characters
It would be better if the draft has the character ("Ctl-L") at page
boundaries.
3. redundant white space characters
It seems to me the draft has white space characters (" ") at each end
of lines. It's probably better to remove them (at least it helps
shrink the total size of the file:-)
4. Introduction
IPv6 stateless address autoconfiguration provides a way to
autoconfigure either fixed or mobile nodes with one or more IPv6
addresses, default routes and some other parameters [3][4].
As indicated by the two references, just saying "IPv6 stateless
address autoconfiguration" is not enough. The Neighbor Discovery
protocol also provides a way of configuration.
5. Section 3.1
The configuration of DNS server address can be
performed manually by operator or automatically DHCPv6 client
running on the router.
We need some clarification here to apply "dynamic *HOST* configuration
protocol" to the *router*. Yes, we did a similar usage for prefix
delegation (RFC3633) where a requesting *router* acts as a DHCPv6
client. In my understanding, however, that was a very special case
which can be considered as an exception. Even if we agree on using
the same logic again, I still believe this document should clarify the
point explicitly.
6. Section 3.1.1 (Advantages of the RA option)
The draft says
1) The RA option is a simple extension of existing ND/Autoconfig
mechanisms [3][4]. No new protocol mechanisms are needed and
extending an ND implementation to support this option should be
very simple.
I don't think this is a valid statement. I'd rather remove this item,
or at least I'd heavily reword it to be fair.
First, the meaning of "no new protocol mechanisms are needed" is
vague. In the sense that we need an unstandardized extension to the
base ND protocol, we need a "new protocol mechanism" for the RA option
approach (on the other hand, we don't need any "new protocol
mechanism" for the DHCPv6 approach in this sense). If you mean the
granularity of, say, the whole ND or the whole DHCPv6 by a "protocol
mechanism", then this advantage will also apply to the DHCPv6 approach
(and probably to the well known address approach as well). So, to be
fair, we'll need to repeat this advantage for all the other
approaches, or we might simply remove this trivial advantage among the
considered three. I'd personally prefer the latter.
Secondly, even if we decide to keep this advantage, I would reword
it without using the term "simple." I often feel people tend to use
this word when they just prefer something over some other things by
saying the former is "simpler" than the latter. At very least,
"simple" is a subjective term and is in general inappropriate in a
technical document. (The same comment could apply to all the other
occurrences of "simple" in the document, but I think this one here is
particular important since this is explicitly counted as an
"advantage" of a particular approach).
Without having "simple", this statement would be just like this:
1) No new protocol mechanisms are needed.
Note that my first comment still holds.
7. Section 3.1.2 (Disadvantages of the RA option)
I think this document should include another disadvantage of the RA
option: we need to configure the RDNSS addresses at least at one
router on every link where this information needs to be configured by
this mechanism.
If there is a hidden assumption that the router can be autoconfigured
with the RDNSS addresses by DHCPv6, see comment 5 above. Also, if we
take this approach, one of the advantages of the RA option may
plummet: address renumbering case, since DHCPv6 may not be able to
update the address quickly.
With DHCPv6, we can mitigate the configuration load with multicast
routing. Of course, deploying multicast routing can be another
barrier of deployment, so there is a tradeoff.
With the approach of well known addresses, the configuration load will
depend on how much we should do to set up routing for the well known
addresses. In an extreme (but not so rare) case where no route
filters are configured within the administrative domain, we basically
should not have to do anything special in routers.
8. Section 3.2 (DHCPv6 Option)
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
clients. [...]
In my understanding, DHCPv6 reconfigure can only be used for the
"stateful" mode of the protocol. At very least, RFC3736 does not
require implementing reconfigure message, so implementations that only
conform to RFC3736 may not support reconfigure mechanism.
I believe this document should explicitly note this limitation.
9. Section 3.2.1 (DHCPv6 Advantages)
5) Hosts in some environments are likely to need DHCPv6 for other
configuration information.
This statement is quite vague for me. Please be more specific on
"some environments".
10. Section 3.2.1 (DHCPv6 Advantages)
7) Interoperability among independent implementations demonstrated
at TAHI and Connectathon.
I'm not sure if particular event names are suitable in an RFC (I'm
just wondering; I don't have a particular opinion on this, and I, for
one, can live with or without the event names).
11. From Section 3.2.3 (DHCPv6 Observations),
I have an impression that the use of the RA option approach will be
very limited to "special applications". However, I have a different
impression from Section 3.1, which seems to say the RA option is a
generic solution.
If my understanding is correct, then I hope the document will be
consistent on this. Even if it can't, then it should clarify why two
different opinions (which might even contradict with each other)
appear in this single document.
12. Section 3.3 (Well-known Anycast Addresses)
I believe this draft should clarify that "anycast" is a different
notion from the one defined in the IPv6 addressing architecture (e.g.,
RFC3513). For example, reference [9] of this draft requires using the
anycast address as a source address for TCP responses while the
address architecture prohibits this usage.
13. Section 3.3 (Well-known Anycast Addresses)
Readers would expect the same organization for this section as that
for Sections 3.1 and 3.2: general description, advantages,
disadvantages, and observation. It might be helpful for readers if
Section 3.3 can use the same organization.
(This is just a comment, and not a requirement for advancing the
document)
14. Section 3.3 (Well-known Anycast Addresses)
Well-known anycast addresses can be combined with cryptographic
security such as TSIG or DNSSEC. However, there is no point to
avoid manual configuration of DNS when secret information (such as
a shared secret key or a public key of root zone) for the
cryptographic security must manually be configured (and updated
periodically).
I don't understand the role of this paragraph in the context of this
section or of the entire document...perhaps additional background
might help or we can simply remove this paragraph?
15. Section 4 (Interworking among IPv6 DNS Configuration Approaches)
For ordering between RA and DHCP approaches, O (Other stateful
configuration) flag in RA message can be used [5]. If no RDNSS
option is included and O flag is set on in RA message, an IPv6 Host
may perform DNS configuration through DHCPv6 [6]-[8].
Note that we are going to loosen the relationship between the O flag
and the invocation of DHCPv6 in rfc2462bis. Right now, I'm not sure
how we can reflect the forthcoming change in this document though (or
whether we need to reflect that in the first place).
16. Section 5.2.1 (Multi-level Network Topology)
The rest of routers below can automatically configure
DNS information through DHCPv6.
The same note on the use of DHCPv6 to routers applies here (see
comment 5 above).
Additionally,
For redundancy and load sharing, well-known anycast
addresses can be used by IPv6 hosts through RDNSS RA option.
This statement seems to contradict with Section 3.3 where the draft
says anycast addresses are not for redundancy.
17. Normative References
There are two work-in-progress documents:
draft-jeong-dnsop-ipv6-dns-discovery-01.txt
draft-ohta-preconfigured-dns-01.txt
Can't we have these as normative references unless these are published
as a stable document (presumably an RFC) before the publication of
this document or at least synchronously? Or is that actually the
plan?
EDITORIAL COMMENTS
18. (throughout the document)
Whereas this document seems to try using Recursive DNS Server (or
"RDNSS") instead of just "DNS server(s)" throughout the document,
there are still many occurrences of the phrase like "DNS server".
Just one example in Section 3.1 (page 4):
The configuration of DNS server address can be
performed manually by operator or automatically DHCPv6 client
running on the router.
Even abstract contains the phrase.
I believe the document should perfectly be consistent on this.
19. In Section 3.1
The RA approach is useful in environments where the addresses of
the recursive DNS servers is changing because the RA option
"is changing" should be "are changing"
20. In Section 3.3 (Well-known Anycast Addresses)
DNS clients have redundancy by having multiple resolvers that there
should be multiple well-known anycast addresses configured on
clients.
I can't parse the sentence...does this mean, e.g, the following?
DNS clients have redundancy by having multiple well-known anycast
addresses configured as RDNSS addresses.
21. In Section 5.1.1 (RA Option Scenario)
For easy configuration on the ISP,
DNS information, unsolicited RA message including a new DNS option
can be delegated to its subnet periodically.
I can't parse this sentence. In particular, I don't understand the
role of the phrase "DNS information" in this sentence.
22. In Section 5.3.3
3) Scalability and reliability of DHCPv6 in very large 3GPP
networks
(with tens or hundreds of millions of UEs) may be an issue, at
[...]
The second line seems to be too short (as a part of a single
sentence).
Similarly,
4) It is sub-optimal to utilize the radio resources in 3GPP
networks
for DHCPv6 messages if there is a simpler alternative available.
The second sentence seems to be too short.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
