>>>>> On Wed, 23 Jun 2004 04:19:59 +0900, >>>>> Masataka Ohta <[EMAIL PROTECTED]> said:
>> 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. > Yup. The fundamental difference to is that it is assumed to be > administratively prohibited to have anycast servers sharing an > anycast address in a single link. Then, most of instabilities > disappear. My first point is that readers would be confused about the meaning of "anycast" (since the address architecture officially defines a slightly different notion). I'll be happy as long as the draft explicitly notes these two are different. >> 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? > The intention is to say that there is no secure ND nor secure DHCP, > unless you manually configure a lot. :-) Understood, but it's very hard, at least for me, to imply the intention from this paragraph; it even doesn't contain "ND" or "DHCP" at all. > With the current security consideration section, the paragraph can > be removed. Okay, then I'd suggest to remove this paragraph (mainly for readability). I can also live with it in Section 3.3 if it provides more context and explains the intention. >> 16. Section 5.2.1 (Multi-level Network Topology) (snip) >> 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. > Huh? 3.3 of the draft says: > Large ISPs may operate multiple recursive resolvers at each > anycast address to distribute and reduce load Yes, but I didn't talk about the "reducing load" part, but about redundancy. My point here is as follows. Section 3.3 says DNS clients have redundancy by having multiple resolvers that there should be multiple well-known anycast addresses configured on clients. There is no point to have multiple servers sharing an anycast address on a single link. (BTW: I couldn't really parse the first sentence as I said in my first message) I interpreted this to mean anycast addresses are not for redundancy (i.e., it seems to me this paragraph insists redundancy should be provided by using multiple addresses, not through the characteristics of anycasting). But then section 5.2.1 says For redundancy and load sharing, well-known anycast addresses can ^^^^^^^^^^^^^^ be used by IPv6 hosts through RDNSS RA option. which seems to me inconsistent with what Section 3.3 said about 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? > ID can refer anything. Sure, if we were not in a wg last call, I'd never make this kind of comment. But we are actually in a last call, and, in my understanding, the goal (or at least one of the goals) of the document is to publish this as an informational RFC. For example, one co-author clearly said so in the following message: http://darkwing.uoregon.edu/~llynch/dnsop/msg02886.html Section 5 of the draft also says: The main objective of this work is to provide a useful guideline as Informational RFC. As you said in a separate message, if this draft won't become an RFC, then I don't care about these things. Even if it will, we could postpone the decision just before the publication. However, I'd try to resolve these issues at this timing, since completing this work seems urgent and it would be better to kill boring process-wise showstoppers as early as possible. Anyway, I personally do not mind with delaying the decision as long as the authors understand the implication and if they still want to do so. 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
