Hello,
I'm about to submit a new revision of the advanced API (rfc2292bis)
draft, mainly in response to comments from you two (thanks, again, for
the comments). Most of the changes are trivial or based on consensus
in this list. However, I'd like to make an explicit response to some
of the comments in order to make it sure that the changes have
addressed the comments. If the changes still have some problems,
please make a quick (negative) ack.
A comment from Thomas:
>> 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?
In the next revision Section 10.1 (for inet6_opt_init()) will have the
following paragraph:
(Note: since the return value on success is based on a "constant"
parameter, i.e. the empty extension header, an implementation may
return a constant value. However, this specification does not
require the value be constant, and leaves it as implementation
dependent. The application should not assume a particular constant
value as a successful return value of this function.)
Also, "prevlen" parameters in function prototypes for inet6_opt_xxx()
will be changed to "offset".
Comments from Jack:
> - section 11.1 you should cite one or more references upon which
> this statement is based:
> "Also, path MTU discovery for multicast has severe scalability
> limitations and should thus be avoided by default."
I could not find a good reference for this sentence, but after
re-reading the entire section, I think the wording could have been
better without additional references. I'd propose the following
paragraphs which replace the paragraph containing the sentence Jack
mentioned:
[RFC-1981] describes how path MTU discovery works for multicast
destinations. From practice in using IPv4 multicast, however, many
careless applications that send large multicast packets on the wire
have caused implosion of ICMPv4 error messages. The situation can be
worse when there is a filtering node that blocks the ICMPv4 messages.
Though the filtering issue applies to unicast as well, the impact is
much larger in the multicast cases.
Thus, applications sending multicast traffic should explicitly enable
path MTU discovery only when they understand that the benefit of
possibly larger MTU usage outweights the possible impact of MTU
discovery for active sources across the delivery tree(s). This
default behavior is based on the today's practice with IPv4 multicast
and path MTU discovery. The behavior may change in the future once
it is found that path MTU discovery effectively works with actual
multicast applications and network configurations.
> I also want to point out an issue that might be raised if this
> API is ever brought to the Austin group (IEEE/OpenGroup/ISO) for
> standardization. The functions and macros listed below use a variety
> of data types for things that represent a "size", including int,
> unsigned int, and size_t. All these items, or at least those of
> type size_t, could instead be of type socklen_t. Note that some
> of the items identified are for use with msg_controllen and cmsg_len,
> which are type socklen_t.
In the next revision all size_t types will be changed to "socklen_t"
or "int". The new type will be "socklen_t" whenever possible, but the
type of function return values will be "int" if it can be a negative
integer (as an error result). If such return values are intended to
be used as input to other functions, the type of the corresponding
arguments will also be "int". For example, the return type of
inet6_opt_init() and the 3rd argument of inet6_opt_append() will be
left as "int".
The return and argument types of CMSG_SPACE and CMSG_LEN will be
changed to socklen_t, considering the intended usage, in spite of the
following comments from Jack:
> Given that CMSG_SPACE and CMSG_LEN were defined in RFC 2292, and
> that their definitions have not changed in 2292bis, and that they
> do not used size_t, I'd vote for leaving them as is.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
