Subject: RE: W.G. Last Call on "Basic Socket Interface Extensions for IPv6"

From: "Dave Thaler" <[email-masked]>
Date: Wed, 21 Feb 2001 16:51:16 -0800

> Please send substantive comments to the ipng mailing list, and minor
> editorial comments to the authors.  This last call period will end two
> week from today on March 7, 2001.

Since some of my comments to the authors on 1/25
are substantive, and none have yet been addressed,
I'm resending to the ipng mailing list as requested.

Point #6 is controversial, and arguments for both sides have each
been presented by multiple proponents on the apifolks list.

1) Section 3.5 talks about creating an "IPv6/UDP" socket
    with a socket call with PF_INET6.  Later, in section 3.7, the
    reader finds out that it isn't an "IPv6/UDP" socket at all,
    but a sort of hybrid IPv6+IPv4/UDP socket.  To create
    a pure "IPv6/UDP" socket, one needs to also use the setsockopt
    described in 5.3.  It would be nice if the discussing in 3.5 
    wasn't so misleading.  For example, how about adding a
    parenthentical forward reference like:

OLD:
> Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
NEW:
> Applications may create IPv6/TCP and IPv6/UDP sockets (which may
> also handle IPv4 communication as described in section 3.7) by simply
> using ...

2) Section 5.2's first sentence seems to limit applicability to UDP.
   Neither this document, nor 2292bis mentions that these can be used
   with RAW sockets (or conceivably non-UDP dgram sockets if anyone
   defines one).  This needs to be fixed in one place or the other.
   My own preference would be for this section to just say these options
   will fail on SOCK_STREAM sockets, and leave it at that.

3) The description of IPV6_MULTICAST_IF should say (as is done for
   IPV6_JOIN_GROUP) what happens if the app specifies 0.
   (I believe this should tell the kernel to choose one.)

4) IPV6_LEAVE_GROUP is similarly terse.  If the app passes 0 as the
   interface to IPV6_JOIN_GROUP, the current wording implies that
   it has to magically figure out which interface the kernel chose
   and specify that interface in the leave.  The wording should
   be updated to say that the value of the interface field should match 
   whatever the app used in that field in its IPV6_JOIN_GROUP call.

5) Section 5.3's title uses "IPV6_ONLY" whereas the socket option
   is IPV6_V6ONLY.  These should be consistent, or else the title
   shouldn't contain something that looks like a defined constant.

6) Section 5.3 states that the ipv6-only option is off by default.
   Like the discussion of bind semantics where we agreed to disagree,
   I strongly object to this as a requirement, for somewhat analogous 
   reasons.  Some stacks today (ours being one of them) are such that 
   the behavior is "on".  Changing the default will break apps.
   As with bind semantics, IMHO it's better to put the burden of always 
   setting the option, on apps that need to be portable across OS's,
   rather than apps that are written for a single OS (whether it
   be Solaris 8, Windows, Linux, or anything else).  The only reason 
   this is a problem is that both stacks and apps already exist that 
   people depend on the behavior being "on" by default, and I believe 
   it's too late to force everyone to change.  Sad but true.

7) In section 6.2, a strange character is present where an 
   apostrophe should be, in two places:
> name will not be returned. If the node^?s name cannot be located, the
                                        ^^ here
> host^?s name cannot be located.
      ^^ here

8) In section 6.4:
> [...]  Note that IN6_IS_ADDR_LINKLOCAL
> and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6
> unicast addresses. [...]

I believe "types of" should be inserted after "two". 
There's certainly more than two local-use unicast addresses...
Furthermore, it would help to illustrate the point by explicitly
stating what the result of the test
IN6_IS_ADDR_LINKLOCAL( ::1 )
is, especially in light of the fact that the scoped-arch document
says ::1 is link-scoped (i.e. it should return false, and it's
worth noting this, similar to the current note about multicast
addresses).

-Dave
--------------------------------------------------------------------
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: [email-masked]
Date: Thu, 22 Feb 2001 12:52:58 +0900

>> week from today on March 7, 2001.

	Just to make sure: with 2553bis-03 draft, the comment from Jason Thorpe
	regarding to constness of gai_strerror return type is not addressed.
	Quoting Jim:

>good catch Jason...and your right (yes it is constant)..
>I will fix things like this before the last draft for the rfc editor.
>I will find someone to go talk to austin.  I don't now that I am at nokia.
>but I still know the austin folks.

	so I hope it to be addressed before it becomes RFC.

	(as jim may have guessed) I second Dave on his point #6.  I believe
	we should not ignore deployed codebase (not just operating systems,
	but also third party applications all around us) when we make updates
	to API.

itojun