>>>>> On Wed, 2 Oct 2002 16:29:50 -0400 (EDT),
>>>>> Jack McCann <[EMAIL PROTECTED]> said:
> So I took a look at 2292bis-07.
Hello, thanks for the valuable comments.
> Some comments for alignment with the latest POSIX standard:
> - I suggest you update the Posix references, using the same
> reference as 2553bis, which I show below (note the spec has
> now also been approved by ISO):
Thomas also asked the update. I'll do that in the next rev.
> - protocol family constants (PF_xxx) are not defined in this
> latest POSIX standard, replace all PF_xxx with AF_xxx
> (e.g. PF_INET -> AF_INET)
Yes, PF_xxx was already replaced with AF_xxx in my local copy. The
fix will appear in the next rev.
> - section 21.1 shows msg_iovlen as type size_t,
> the latest POSIX defines msg_iovlen as type int
OK.
> Some editorial comments:
> - section 7.1 in this sentence, CMSG_LEN should be CMSG_SPACE (see
> the nice diagram on page 67, an "ancillary data object" includes
> the padding at the end)
You're right. Thanks for the correction.
> - section 8 typo in first paragraph last sentence "Hob-by-Hop"
Ditto.
> - section 10.5 inet6_opt_next, the statement "Typep points the option
> type field" does not seem right, for typep to point to the option
> type field, it would have to be passed as 'uint8_t **typep'; I think
> you mean it points to a buffer into which the option type is stored,
> or using wording similar to lenp, "typep stores the option type"
Ditto. I'll change this part to "typep stores the option type".
> - 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."
Hmm, I thought this was a kind of common sense these days, but there
seems to be no RFC talking about the scalability issue of multicast
path MTU discovery. Does anyone in this list know a good reference?
> A minor technical comment:
> - There is an inconsistency in the inet6_opt_set_val and
> inet6_opt_get_val functions. In both functions, the offset
> argument is type size_t, but the function return value (also
> an offset) is type int. Given the intended usage of these
> functions, where the return value of one call can be used as
> the offset argument on the next call, the data type of the
> offset argument should be type int.
> 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.
OK. I'll check the entire draft and change length types accordingly.
Thanks,
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]
--------------------------------------------------------------------
