JINMEI Tatuya wrote: > > > Please let me make sure about this comment...are you proposing to > > remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper > > position of a destination options header (only with the IPV6_DSTOPTS > > option)? > > > => yes > > > If so, how can a user specify a couple of destination > > options headers before and after a routing header? > > > => he cannot but he doesn't need it and he cannot specify > > a destination option header just before a fragmentation header. > > IPV6_RTHDRDSTOPTS is unnecessary and misleading. > > Hmm, I admit that the single IPV6_DSTOPTS would be enough for today's > (even "advanced") applications. So I, for one, can live with the > single option. However, I'm also quite sure this part is > controversial. I'd like to know others opinions...
Well, for one, I don't see a good enough reason to remove this. This particular interface allows the user to specify the header that is discribed in 2460. Remembering how much discussion (trouble) we all had figuring out this DO Header stuff, I would leave this particular option there. This way, anyone trying to use 2460 header ordering can do so. > > >> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex) > > > Do you mean the send() message should return an (immediate) error when > > the packet is not fit in the outgoing link MTU? But, as Erik > > explained in his reply to Vlad, we cannot always expect the immediate > > error. I admit the spec is a bit complex, but the spec should be > > generic enough (i.e. we cannot assume a particular type of OSes.) > > > => I've read Erik's answer but just try to explain the MTU stuff to > > a common programmer... > > So, what do you want in this section? Are you requiring a change > here? If so, please be more specific. > Would you agree on adding the text similar to Section 6.6 about an additional error message on sendmsg(). The precendence is already set by Section 6.6, but I don't have a very strong opinion on this. > >> - 11.5: is IPV6_REACHCONF really useful (example)? > > > Honestly, I personally do not see a practical usage of this option. > > At least I've never seen an application that uses it. I don't mind to > > remove this, but if any other person wants to keep it, I'll just leave > > the current text as is. The definition has been there since a quite > > old revision of the draft, and it can at least be implemented. > > > => I don't believe the "it can at least be implemented" argument is > > enough to keep something (the opposite is :-). > > Fair enough. Again, I don't mind to drop this section unless someone > wants to keep it. > No strong opinions about this. For most short communications (e.g. UDP) it may not be very usefull (particularly in view of DELAY_FIRST_PROBE_TIME being 5 seconds, so NUD waits a while). For long communications, it probably will not be usefull either. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
