In your previous mail you wrote: > 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...) => sorry...
> - 0: is it time to alias sin6_scope_id to sin6_zone_id (far better name > but not suitable for the basic API)? 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. => will be for the next version of the basic API... > - 2.2.2: ND_RA_FLAG_HA (for Mobile IPv6) is missing One of the main decisions in recent revisions of this draft is... => so we have to require the definitions somewhere (a rfc2292ter I-D?) > - 6.1: IPV6_PKTINFO/IPV6_MULTICAST_IF precedence is defined... Section 6.7 describes how the outgoing interface is chosen. => I've missed this forward reference! > - 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? => examples of a well known value are code points of class selectors (but they are not IPv6 specific). > - 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)? => yes If so, how can a user specify a couple of destination options headers before and after a routing header? => he cannot but he doesn't need it and he cannot specify a destination option header just before a fragmentation header. IPV6_RTHDRDSTOPTS is unnecessary and misleading. > - 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.) => I've read Erik's answer but just try to explain the MTU stuff to a common programmer... > - 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? => there is already a document about this so I don't believe you need to modify the 05 draft. This is more a remark for the other document (BTW I've found a candidate for the previous point :-). > - 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. => I don't believe the "it can at least be implemented" argument is enough to keep something (the opposite is :-). > - 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.) => yes, please remove IPV6_RTHDRDSTOPTS from everywhere. Thanks [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] --------------------------------------------------------------------
