Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-08.txt

From: [email-masked]
Date: Thu, 17 Oct 2002 07:34:17 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Advanced Sockets API for IPv6
	Author(s)	: R. Stevens, M. Thomas, E. Nordmark, T. Jinmei
	Filename	: draft-ietf-ipngwg-rfc2292bis-08.txt
	Pages		: 83
	Date		: 2002-10-16
	
This document provides sockets APIs to support 'advanced' IPv6
applications, as a supplement to a separate specification, RFC 2553.
The expected applications include Ping, Traceroute, routing daemons
and the like, which typically use raw sockets to access IPv6 or
ICMPv6 header fields.  This document proposes some portable
interfaces for applications that use raw sockets under IPv6.  There
are other features of IPv6 that some applications will need to
access: interface identification (specifying the outgoing interface
and determining the incoming interface), IPv6 extension headers, and
path MTU information.  This document provides API access to these
features too.  Additionally, some extended interfaces to libraries
for the 'r' commands are defined.  The extension will provide better
backward compatibility to existing implementations that are not
IPv6-capable.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipngwg-rfc2292bis-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 17 Oct 2002 23:42:20 +0900

>>>>> On Thu, 17 Oct 2002 07:34:17 -0400, 
>>>>> [email-masked] said:

> 	Filename	: draft-ietf-ipngwg-rfc2292bis-08.txt

I believe I addressed all the points you provided (as an AD review)
and related comments from Jack (McCann) in this revision, and so the
draft should be ready for an IESG review.  If you also think this is
okay, please pass it to the IESG.

Just FYI, below I've attached the change list, and briefly explained
that I addressed your comments citing your original message.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Here is the change list:

   -  Changed the type of some function arguments and return values from
      size_t to int or socklen_t to be aligned with the latest POSIX.
      Revised code examples accordingly.

   -  Used PF_xxx instead of AF_xxx.

   -  Replaced MUST with must.

   -  Made the URL of assigned numbers less specific so that it would be
      more robust for future changes.

   -  Changed the reference to the basic API from RFC2553 to the latest
      Internet Draft.

   -  Added a sentence to mention that this document is intended to
      replace RFC2292.

   -  Revised abstract to be more clear and concise, particularly
      concentrating on differences from RFC2292.

   -  Removed traceroute as a usage of returning the received hop limit.

   -  Moved new definitions about CMSG_xxx from appendices to the
      document body.

   -  Added a reference to the latest POSIX standard.

   -  Clarified that inet6_opt_init() may return a constant, but this
      document left it as implementation dependent.

   -  Changed the argument name "prevlen" in inet6_opt_xxx() function
      prototypes to "offset", which better describes the intended usage.

   -  Revised the text about the minimum MTU for multicast to make it
      clear that the default behavior came from operation practices.

   -  Many other style and wording improvements.

(end of the list)

Here are brief responses to your comments:

>>>>> On Tue, 06 Aug 2002 16:05:34 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

> Abstract:

> take out the references; saying "rfc 2553" without making it a
> reference is OK. See the RFC editors guidelines on abstracts for more
> details (draft-rfc-editor-rfc2223bis-02.txt).

> Note: the abstract itself could really be rewritten to be more
> clear/concise.

=> I've totally rewritten abstract.

> Early in the introduction, the document should say it is
> updating/replacing the RFC 2292.

=> done.

> General: it would be good to have a proper reference to the posix
> standards in the references section. I.e.:

=> done.

>> 4.3BSD Reno sockets API in 1990.  The reason is that these ancillary
>> data fields are part of the Posix.1g standard and should therefore be
>> adopted by most vendors.

> Also, how does this align with the Austin group work and the revised
> basic API? Are the documents in sync with each other? I say this
> because the Basic API is apparently in alignment with the Austin Group
> work. It would probably be useful to have some text saying how this
> document relates to that standard.

> Also, take a look at the most recent changes to the basic API. Do any
> spill over into this document? One change to the basic API that seems
> relevant to this one:

=> At least I've tried to make the document aligned with the standard
as much as possible, with great help from Jack.

>> .  More alignments with [3]:
>> - [3] does not contain protocol family definitions (PF_xxx).
>> Replaced PF_INET6 with AF_INET6, or removed as appropriate.

> This document still refernces PF_INET, etc.

=> fixed.

> I note that there are some new ICMP types that have been assigned that
> this document doesn't seem to reference (e.g., those greater than
> 138). Should they be added?

=> We've agreed that we do not need additional definitions.

>> are taken from http://www.iana.org/assignments/protocol-numbers.

> this URL should be restricted to http://www.iana.org/numbers.html (the
> URL in the document is not stable over long periods of time)

=> fixed.

>> All data sent via raw sockets MUST be in network byte order and all

> s/MUST/must/? (this document doesn't really use MUST/MAY/SHOULD
> language). Either downcase this usage here, or include a definition
> (e.g., a reference to the 2119 definitions).

=> replaced with must (not MUST).

>> In order to clear an installed filter the application can issue a
>> setsockopt for ICMP6_FILTER with a zero length.  When no such filter
>> has been installed corresponding getsockopt() will return the kernel
>> default filter.

> last part doesn't parse quite right.

> s/installed corresponding/installed, / ??

=> fixed.

>> We note that many of the functions and socket options defined in this
>> document may have error returns that are not defined in this
>> document.  Many of these possible error returns will be recognized
>> only as implementations proceed.

> This might have been true the first time this document was
> produced. Is it still true today?

=> basically yes, as I answered before in this list.  I've slightly
modified the wording though.

>> 4.3BSD Reno sockets API in 1990.  The reason is that these ancillary
>> data fields are part of the Posix.1g standard and should therefore be
>> adopted by most vendors.

> why are there appendices? seems like at least some of these are part of
> the spec itself. Putting them in the appendices would imply that they
> perhaps aren't important.

=> moved extensions in this document to the body (not appendices).

> Re: references to RFC 2553; should they point to the revised ID
> instead? (since it is about ready to become an RFC)

> note: "int " is used throughout. Is this a short/long int? Does this
> need to be clarified, or is the current usage adequate?

=> as I answered in this list, all the "int" should be okay.

>> inet6_opt_set_val()  - add one component of the option content to the option
>> 
>> Three functions deal with a returned options header:
>> 
>> inet6_opt_next()     - extract the next option from the options header
>> inet6_opt_find()     - extract an option of a specified type from the header
>> inet6_opt_get_val()  - retrieve one component of the option  content

> some of the lines go beyond column 80(?). Rfc editor won't allow
> that. Can you reformat to keep lines within acceptable length? (Check
> the RFC editor formatting rules for details.)

=> fixed.

>> 5.  Extensions to Socket Ancillary Data
>> 
>> This specification uses ancillary data as defined in Posix.1g with
>> the following compatible extensions:

> should this ID also include text relative to the austin group work?

=> done (added a proper reference).

>> -  A new CMSG_SPACE macro is defined.  It is used to determine how much
>> space need to be allocated for an ancillary data item.  See Section

> s/need/needs/

=> fixed.

>> operation.  Returning the received hop limit is useful for programs
>> such as Traceroute and for IPv6 applications that need to verify that
>> the received hop limit is 255 (e.g., that the packet has not been
>> forwarded).

> how does this help traceroute? Traceroute needs to set, not receive
> the ttl.

=> traceroute as an example was removed.

>> To specify the outgoing traffic class value, just specify the control
>> information as ancillary data for sendmsg() or using setsockopt().
>> Just like the hop limit value, the interpretation of the integer
>> traffic class value is
>> 
>> x < -1:        return an error of EINVAL
>> x == -1:       use kernel default
>> 0 <= x <= 255: use x
>> x >= 256:      return an error of EINVAL

> note that the terminology surrounding diffserv/traffic class has
> changed (see RFC 3260). Is the current API still OK? there are only 64
> diffserv values now. (I think this is OK, but the authors should recheck).

=> made it sure that this is okay.

>> ENXIO         The interface specified by ipi6_ifindex does not exist
>> 
>> ENETDOWN      The interface specified by ipi6_ifindex is not enabled for
>> IPv6 use.
>> 

> Indention not right. (too far to left)

=> fixed.

>> This document and [RFC-2553] specify various methods that affect the
>> selection of the packet's outgoing interface.  This subsection
>> summarizes the ordering among those in order to ensure determined
>> behavior.

> s/determined/deterministic/?

=> fixed (replaced with deterministic).

>> every multicast packet on the corresponding socket.  The reason for
>> the ordering comes from expectation that the source address is
>> specified as well and that the pair of the address and the outgoing
>> interface should be desired.

> s/desired/preferred/?

=> fixed (replaced with preferred).

>    Source routing with IPv4 sockets API (the IP_OPTIONS socket option)

> s/with/with the/ ?

=> fixed (replaced with "with the").

>> int inet6_opt_init(void *extbuf, size_t extlen);
>> 
>> This function returns the number of bytes needed for the empty
>> extension header i.e. without any options.

> I don't understand this sentence. Does this then always return the
> same value? And doesn't an "empty" header require 0 bytes? Or is this
> actually "length remaining"?

> Actully, the "length" field is weird in subsequent usages to. Is it
> really a length, or an offset into the options? Calling it length is
> confusing. Is it too late to change this?

=> added more text to clarify this.  also, the parameter name
"prevlen" was changed to "offset".

>> -  The new inet6_opt_XXX() functions were made different that the old

> s/that/than/

=> fixed.
--------------------------------------------------------------------
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: Thu, 17 Oct 2002 23:45:18 +0900

>>>>> On Thu, 17 Oct 2002 23:42:20 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

>> instead? (since it is about ready to become an RFC)

It now referred to the revised ID.

					JINMEI, Tatuya