>>>>> On Thu, 17 Oct 2002 07:34:17 -0400,
>>>>> [EMAIL PROTECTED] said:
> 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
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 PROTECTED]
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 PROTECTED]> 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 PROTECTED]
--------------------------------------------------------------------
