- Ralph
At 02:38 PM 6/22/2004 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
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
All eight people contributed text and reviewed the entire document. Perhaps the author list should be reorganized as one editor, with all eight people listed in a "Contributors" section.
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.
Interesting point. In my mind, there is some room for interpretation of the interfaces on a router acting as "host" or "router" interfaces. I think there was some discussion about the differentiation between interface function as "advertising" or "non-advertising"? In the PD case, the use case is a CPE router, with one interface connected to the ISP network that acts as a "host" interface and one or more interfaces to the customer network acting as "router" interfaces. In this use case, it seems reasonable to allow DHCPv6 on the CPE interface to the ISP.
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.
Suggested change:
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 clients that use stateful configuration assignment.
The following paragraph in the document describes the current work on reconfiguring hosts using stateless DHCPv6.
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".
How about:
5) Hosts that require other configuration information such as the addresses of SIP servers and NTP servers are likely to need DHCPv6 for other configuration information.
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).
Sure; suggested replacement text:
7) Interoperability among independent implementations has been demonstrated.
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).
In particular, the new text in rfc2462bis does not preclude the use of stateless DHCPv6 when the O flag is not set. Thus, a host that requires the address of an RDNSS might well try stateless (or even stateful) DHCPv6 if it doesn't receive an RA with an RDNSS option.
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.
OK.
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.
Re-reading this sentence for intent, I think it should be qualified to the case in which all of the CPEs use the same RDNSS. In the case where different customers use different RDNSSes - for example, in the MSO/ISP - simple broadcast of an RDNSS option in an RDNSS won't be sufficient.
Also, it might be good to be more specific in the case where the CPE is a customer router "gateway", as the expectation would be that the CPE accepts the RDNSS information from the RA on the interface connected to the ISP, and copies that information into the RAs broadcast in the customer network.
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
