Subject: Re: IPv6 w.g. Last Call on "Advanced Sockets API for IPv6"

From: Tim Hartrick <[email-masked]>
Date: Thu, 14 Feb 2002 10:57:45 -0800 (PST)

Jinmei,

> 
> I agree.  If it is really easy to deal with the send side as you said,
> it would be the best candidate (so I'd like to know the details).
> 

I had missed the change in receive side semantics.  More badness.  Why
can't the order of the setsockopt calls establish the order of the
routing header and the destination options?  I don't see why it isn't that
simple except in the case where ancillary data and sticky options are
intermingled.

This is another reason why it was better to allow ancillary data to override
ALL sticky options rather than just like sticky options.  This change has
substantially complicated the implementation for little benefit.  Oh well.

Just put this mess to bed.

tim 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 18 Feb 2002 17:08:09 +0900

(sorry for the delayed response.  I'm just back from a short vacation.)

>>>>> On Thu, 14 Feb 2002 10:57:45 -0800 (PST), 
>>>>> Tim Hartrick <[email-masked]> said:

> I had missed the change in receive side semantics.  More badness.  Why

Let me confirm, did you say the change in the receive side was "more
bad"?  I don't get the relationship between the change in the receive
side and the rest of your message...

> simple except in the case where ancillary data and sticky options are

I don't think it is a good idea to assume the relationship of two
separate (and different) socket options and make application
programmers take care of the ordering.  This approach is in fact
essentially the same thing as IPV6_RTHDRDSTOPTS with additional
confusion; for example, it is not clear on what happens when we remove
a routing header after specifying a couple of destination options
headers.  It is also unclear on how to remove a particular destination
options header after specifying a couple of ones....

I'd rather prefer IPV6_RTHDRDSTOPTS to this approach.

> Just put this mess to bed.

I still strongly believe that the current overriding rule is more
natural for application programmers with the fact we've separated
sticky options as a separate set of single socket options.  Here is a
recap of an old message of mine (in a private discussion).  I think
this is still reasonable enough, and do not think the result is
"little benefit":

    Anyway, first I thought that the previous behavior was natural.
    On the second thought, however, I changed my mind.  The previous
    overriding scheme is reasonable in RFC2292, because we can only
    specify a "set" of options in a single sticky option; IPV6_PKTOPTIONS.

    But, in rfc2292bis, we have separated each option so that it could be
    specified as a single sticky option.  Additionally, we have much more
    ancillary data items/sticky options than in RFC2292, and there is an
    "ancillary-only" option (IPV6_REACHCONF).  Perhaps due to all of these
    points, some applications use both an ancillary data item and a sticky
    option expecting that both of them can be enabled at the same time.
    BIND 9 is an example; it uses IPV6_USE_MIN_MTU as a sticky option for
    the UDP socket as well as IPV6_PKTINFO ancillary data items to specify
    the source address.  If the underlying kernel strictly follows
    rfc2292bis-02, the IPV6_USE_MIN_MTU sticky option would be disabled.

    Of course, we could say that "it's a bug and the application should be
    corrected."  However, I think such a usage of BIND 9 is quite natural
    to application programmers, and what should be changed is the API
    specification.

===
Through the discussion so far, my feeling on this issue is that we
should just go with the current specification.  It's true that
IPV6_RTHDRDSTOPTS is useless at least for now and will probably be
in the foreseeable future.  However, the current spec is clear enough
and is consistent with the policy of adopting the "recommended" order
described in RFC 2460 as a limitation within this particular API spec.

As everyone admits (I believe so), we do not need a "perfect"
specification; the most important thing is to provide application
programmers with a uniform API that can cover today (and the
foreseeable future)'s typical applications.  We should be able to live
with the spec as long as it is clear enough.

If necessary, we can add a note that there is no use of
IPV6_RTHDRDSTOPTS as of writing the API and that applications will
only need IPV6_DSTOPTS in most cases.

Can we agree with this?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------