> 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 PROTECTED]
--------------------------------------------------------------------
