On Thu, 26 Sep 2002 13:03:53 +0900
JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]> wrote:
> >>>>> On Wed, 25 Sep 2002 13:52:58 -0700,
> >>>>> Michael Hunter <[EMAIL PROTECTED]> said:
[4 people's opinions about ip6r0_addr]
> (correct me if I'm wrong or miss someone.)
That is as I read it.
[...]
> > [...]
> >> Another thought: most user applications are expected to use
> >> inet6_rth_xxx functions, instead of directly getting access to the
> >> address part following the rthdr[0] structure. Thus, either 1 nor 2
> >> affects the typical user applications.
>
> > So why create incompatibilities with 2292 if you expect the feature
> > being broken to be used less in the future? Whats the gain?
>
> See Vlad's response.
So the gain was:
1) it would make it more consistent with the rest of the API
2) it makes handling a corner case cleaner
I personally don't see these as a strong enough reason to break the
API.
I strongly disgree with Vlan'd comment that "Additionally 2292bis has
some other incompatibilities with 2292 this one being the least of the
problems. So that argument doesn't fly." Thats a slippery slope
leading you to completely abandoning backwards compatability. You
should have strong technical reasons for each and every breakage of the
API independent of what else you have broken.
[...]
> Additionally, I suspect the removal actually breaks user code so much.
> As I said before, user applications are usually expected to use
> library functions for source routing and to not use the ip6r0_addr
> member directly. In fact, we, the KAME project, do not use the member
> name in about 80 IPv6 applications we provide. I also searched on
I think this is overstating your case. This is the advanced API. You
don't expect it to be used in many of you applications. The real point
is that you don't use it in the less then 5 (ping, telnet, traceroute,
'sniffer') applictions that might need it.
> recent source code of FreeBSD and NetBSD (which have not supported
> 2292bis yet). The only occurrence of ip6r0_addr other than in user
> applications is in tcpdump, where no compatibility issue exists since
> tcpdump uses its own header definitions.
Which is telling about the stability and widespread acceptance of this
API. I think its very likely that one of the reasons they needed
private headers had to do with the variations of API between 2292 and
2292bis.
[...]
> I understand your frustration, but I'm afraid no one can "win" in this
> kind of discussion. We just need a compromise, and I hope you kindly
> allow us to go with the current definition.
[...]
I agree on this point. I'm tired. I'm done. This just isn't THAT
important. Note my "frustration" and go on.
mph
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
