>>>>> On Wed, 25 Sep 2002 13:52:58 -0700, >>>>> Michael Hunter <[EMAIL PROTECTED]> said:
> [...] >> I didn't remember the reason why the member name was removed, so I >> found it from the web. You'll get the answer from the discussion >> starting at the following URL: >> >> http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html >> >> According to the discussion, there seemed to be a clear consensus on >> the removal (though this may not be regarded as a "strong reason"). > poster + > 1 FAM preferred (removal next) > 1 removal > 1 its nice to have the array member > 1 but I don't need the array member I could not tell who is who, so please let me be more concrete. Vlad proposed to remove the member. Francis agreed. Tim agreed. Erik first said the member was useful but then followed the suggestion anyway. (correct me if I'm wrong or miss someone.) > I'm not sure what the overall membership of the interested parties was > but that doesn't sound like a large sample. I'm not sure, either. But API discussions are often like this. > [...] >> 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. >> Having thought all of this, I still prefer the current 2292bis >> definition. (I personally could live with (2), but I prefer (1) over >> (2) because we had a clear consensus on this.) >> >> Can we agree on this, or do we need more discussion? > I'm not buying the reasons I've seen so far for this incompatibility > with 2292. I believe you need a reason other then "its ugly" to break > users code. I think the fact that we can have a routing header without any address is a reasonable reason to remove ip6r0_addr[1] other than the style issue (I guess that's the main reason why Erik added this change in the 01 version of the draft). 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 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. Of course, I'm not saying the above is all of IPv6 applications, but it should definitely covers a noticeable part of them, particularly in the open source area where the compatibility issue is severer. As Vlad said, 2292bis has already broken compatibility to the old RFC2292 in many points (I admit this is a weird thing, but this is the fact and was decided by this community). And the examples above show that this is a relatively minor issue among them in the real world. Thus, I would prefer the new definition in 2292bis because of the reasons Vlad raised. 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. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- 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] --------------------------------------------------------------------
