Hi Jinmei-san, Look at the inlines. ----- Original Message ----- From: <JINMEI Tatuya> Sent: Saturday, July 10, 2004 6:03 PM > > >>>>> 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. >
The second alternative looks good because this feature is an advantage for each approach. For the fairness, I'll include the feature in each approach's advantage. > > 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: > I expect Ohta-san to send his new text to me soon. As soon as I receive it, I'll recompile our draft and submit it to the IETF secretariat. Thanks again for your contribution. Paul > > 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 > . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
