>>>>> On Tue, 12 Feb 2002 14:15:14 +0100,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> Some late comments about draft-ietf-ipngwg-rfc2292bis-04.txt:
Thanks for the detailed comments. (But, yeah, this is a bit late. I
just submitted the 05 version...)
> - 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name
> but not suitable for the basic API)?
I'm tempted to incorporate this into this API spec as a co-author of
the scoping architecture draft, but I don't think the advanced API is
the proper place to define the alias. sockaddr_in6 is definitely a
product of the basic API, so if we decided to define the alias
somewhere, the place should be "a kind of" basic API document. Just
because the basic API spec is in the last stage of standardization
cannot be the reason to define a new stuff in the advanced API. I
hope you accept this position.
> - 2.1.1: IPPROTO_IPCOMP (108, RFC 3173) is missing (as usual :-).
Since this is not specific to IPv6, I don't think we'll have to
incorporate this definition to this API spec (I admit IPPROTO_ESP and
IPPROTO_AH are not specific to IPv6 either, but they are at least
mandatory stuffs in IPv6 and are mentioned in RFC 2460). As I said
the other day, we cannot just incorporate all the miscellaneous
definitions to the advanced API spec...
> - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing
> (note: only some Mobile IPv6 features are enough stable to be added
> today in the advanced API, another way is to mandate the definitions
> for the API in Mobile IPv6 (and other) documents)
> - 2.2.2: draft-ietf-ipngwg-icmp-name-lookups-08.txt ???
> (same issue but the document should be published soon and
> it is too late to add definitions)
One of the main decisions in recent revisions of this draft is that we
should stick to already-standardized definitions, that is, definitions
that are in an RFC status. We did not want to depend on moving targets.
I tend to agree with the icmp-name-lookup stuff, but I believe we can
live without the definitions, at least in this particular API document.
> - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined but
> there is nothing about sin6_scope_id (IMHO the behavior should be:
> raise an error if the interface is not in the zone, i.e. interface
> specification is a more accurate specification).
> 6.2 tries to explain but is not enough clear/formal about this point
> and misses the fact that the issue can be for both sin6_scope_id of
> the source (bind()) and destination (connect/send*()) socket addresses.
Section 6.7 describes how the outgoing interface is chosen. The items
1 to 5 in this section do not depend on the sin6_scope_id value of the
source (specified by bind(2)) and destination (specified by connect(2)
etc) addresses. And then the text says that the implementation should
check the scope zone boundary wrt the outgoing interface and the scope
zone of the source/destination addresses.
Isn't this enough? If not, could you be a bit more specific on how
the text should be?
> - 6.2: why IPV6_PKTINFO is not simply forbidden for TCP (i.e. raise
> an error in place of ignore)?
Hmm, since there probably exists no TCP application that tries to set
IPV6_PKTINFO for specifying the source address, it would be clearer to
forbid this case.
> - 6.5: are some definitions of well known values useful?
> (IMHO this is the job of DiffServ WG to answer)
I'm not sure about this comment. What exactly do you want in this
section? Are you requiring some revise in this section?
> - 9.2: this text should make clear the assumption of RFC 2460 recommended
> ordering is abusive. I propose to remove IPV6_RTHDRDSTOPTS which
> has no current use too, so we can get the same kind of text than
> for routing headers (known limitations, possibility for clever kernels
> (i.e. a kernel which knows that a tunnel encapsulation limit must be
> before the fragmentation header when a packet with a TEL is fragmented)).
Please let me make sure about this comment...are you proposing to
remove IPV6_RTHDRDSTOPTS and to let the kernel choose a proper
position of a destination options header (only with the IPV6_DSTOPTS
option)? If so, how can a user specify a couple of destination
options headers before and after a routing header?
As for the recommended header ordering in RFC 2460, I don't mind to
make more comments that we cannot always assume the recommended
ordering (actually I tried to explain this fact throughout this
document. the ordering is just a limitation in this particular API.).
> - 11.2: I share Vladislav's concerns (the MTU stuff is a bit too complex)
Do you mean the send() message should return an (immediate) error when
the packet is not fit in the outgoing link MTU? But, as Erik
explained in his reply to Vlad, we cannot always expect the immediate
error. I admit the spec is a bit complex, but the spec should be
generic enough (i.e. we cannot assume a particular type of OSes.)
> - 11.4: there is a discussion about MTUs and extra headers added by
> the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should
> not take into account the headers. But this makes it less useful
> for the programmer... (note: this is just a philosophical question
> for the 2292ter)
I understand your concern, but, anyway, the value returned by
IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too
big, the application can then adjust the packet size with succeeding
MTU notification (assuming that it also specifies IPV6_RECVPATHMTU).
So, I'd propose to clarify that the MTU is an "IP MTU" (in your
definition above) and can be larger than the actual current path MTU
when the kernel inserts additional headers. Is it okay with you?
> - 11.5: is IPV6_REACHCONF really useful (example)?
Honestly, I personally do not see a practical usage of this option.
At least I've never seen an application that uses it. I don't mind to
remove this, but if any other person wants to keep it, I'll just leave
the current text as is. The definition has been there since a quite
old revision of the draft, and it can at least be implemented.
> - 12: see 9.2
(again) I'm not 100% sure about the point. Do you propose to remove
IPV6_RTHDRDSTOPTS from this section, too? (If we can reach consensus
in 9.2, I'll of course revise this section accordingly.)
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]
--------------------------------------------------------------------
