In your previous mail you 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...
=> I expect less objections to simplify things than for the opposite...
>> - 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.
=> If there is no proposal for a simpler version, keep it... and
be ready to explain it if someone is getting the strange idea to use it (:-).
Thanks
[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]
--------------------------------------------------------------------
