JINMEI Thanks, this is a lot clearer. I'll try to address the points that you've made since I am still not convinced that we gain anything by changing the behavior.
JINMEI Tatuya / ����� wrote: > Perhaps I was not very clear at the presentation. The reason for the > change (in 03) is NOT security. I intended to say: > > Despite the change with using recvmsg(), the previous (i.e. before > rfc2292bis-03) spec cannot follow all the changes on received > segments. Thus, it cannot be used for security (e.g. access > control) purposes (we need to follow the changes perfectly if we use > the mechanism for security.) Of course, the 03 behavior (like the > one in RFC 2292) cannot be used for security purposes either. > > With this reality, the received optional information can only be > used as "informational" in the sense of the word. This also means > that it is meaningless to try to receive the optional information > for as many received segments as possible. > > So, using recvmsg() with ancillary data has less advantage over the > RFC 2292 behavior, at least IMHO. I don't understand why you are assigning advantage to the 2292 behavior. So far, both methods provide identical functionality as far as the headers received by the application. IMO, both versions add additional complexity to the application, but only at the request of the application. > > Meanwhile, using recvmsg() causes additional issues, such as impact > on the socket semantics or the "send-only apps" problem, which did > not exist in the RFC 2292 behavior. Are you conserned about not being able to access the extension headers sent with ACKs, RSTs, etc...? Is this really something that would be usefull to an application? > > As for the ability to receive optional information at a send-only > application, it might be true that there is less meaningful usage of > the ability. But, anyway, RFC 2292 (and 2292bis-03) provides the > ability, while rfc2292bis-02 (and earlier) does not. I think providing a meaningless ability is pointless and makes for feature bloat and complexity. It is not a good argument to do something. > > In summary, the rfc2292bis-02 behavior has disadvantage over the > RFC2292 behavior without an (less) advantage. > > That's why I, for one, prefer the 03 behavior. But I admit that the > advantage (03 over 02) is not so big and one may say that the > advantage is not worth the change. (perhaps I should have just put > the issue in the "open issues" section. that was my bad.) I prefer the 02 behavior because it is cleaner conseptually. Yes it requires code changes for the apps wanting to use it, but most applications do not need and will not use this feature. > > And, of course, either approach has impact on existing > implementations, and the impact depends on the spec that the > implementations are using. As I said in the presentation, the 02 > approach affects RFC2292-based implementations much, and the 03 > approach affects 02 (or earlier) based implementations much. So I'd > like to hear from other implementors. > > Again, though I prefer the 03 behavior, I know (and understand) some > other people dislike it. I'll hear from others, and will obey the > consensus. If we can not reach consensus (don't gasp, it happened before), may I suggest that we document both behaviors. We can keep a strict 2292bis-02 behavior (i.e don't return control data for SYNs, ACKs, etc), and the 2292bis-03 behavior with the limitations in section 4.1 (i.e applies only to TCP and can only be used with getsockopt). Both calls will return identical information and MUST be used exlucsively of each other (i.e use one or the other, not both). -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
