>>>>> On Fri, 9 Jul 2004 17:37:23 +0900, >>>>> "Jaehoon Paul Jeong" <[EMAIL PROTECTED]> said:
> Your suggestion looks very good. > I need the help of several people: > Juha, Jinmei-san and Ohta-san. I guess you need my help for the last one, so I'll concentrate on that part. >> 4. I don't think Jinmei-san's issues 6 and 13 from >> http://www.uoregon.edu/~llynch/dnsop/msg02915.html were addressed. >> > o About issue 6 related to RA approach, I took Jinmei's second suggestion. > I omitted a word "simple" from the RA text. > The modified text is as follows; > -------------------------------------------------------------------------------------- > 3.1.1 Advantages > The RA option for RDNSS has a number of advantages. These include: > 1) The RA option is an extension of existing ND/Autoconfig mechanisms [3][4]. > No new protocol mechanisms are needed for extending an ND implementation to > support this option. > -------------------------------------------------------------------------------------- This does not address the first part of my concern: the meaning of "(no) new protocol mechanisms" is vague (and can be unfair). According to the response from Bob (Hinden), it should mean: > The intent of "no new protocol mechanisms" text was it was only necessary > to define a new option, not change the ND protocol. Just the same as if > one was to define a new DHCP option, the protocol mechanisms of the DHCP do > not need to change. Does that help? (see also http://darkwing.uoregon.edu/~llynch/dnsop/msg02952.html as a reference) With this clarification, the text should rather be: 1) The RA option is an extension of existing ND/Autoconfig mechanisms [3][4], and does not require a change in the base ND protocol. But we then need to face the fairness issue I pointed out. This "advantage" also applies to the other mechanisms. Actually, we don't even need any new options for the DHCPv6 and WKA approaches. So, to be fair, I'd recommend either A: just remove this advantage because this property is common for all the approaches. (I prefer this option) or B: make similar points for the other approaches as well. For example, revise item 6 of Section 3.2.1 from 6) The specification for configuration of DNS recursive name servers through DHCPv6 is available as an RFC. to 6) The specification for configuration of DNS recursive name servers through DHCPv6 is available as an RFC. No new protocol extensions such as new options are necessary. > o About issue 13 related to WKA approach, > the reorganization of the text can be done by Ohta-san in order to harmonize with > other approaches. I guess you requested Ohta-san's help here, but if I need to say something as the one who made the original comment, I don't think this is a show-stopper while the change would make the document more reader-friendly. In fact, I noted in my original comment that: > 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) 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
