>>>>> On Sat, 15 Dec 2001 02:40:18 -0500,
>>>>> Vlad Yasevich <[EMAIL PROTECTED]> said:
> Since you are soliciting comments from implementors, here are my
> opionions about the change ( I was going to wait until I got to work).
Thanks for the prompt response (and sorry for urging you. If anyone
of you are going to show an opinion after doing some work or check on
the implementation, I'm of course willing to wait for the answer.)
> I beleave the the 2292bis-02 definition and TCP implications were
> fine. I was curious about the reasons this was put in the draft.
> You said at the meeting that you did this for security/access control
> reasons. I don't think that this was necessary. The send-only sockets
> do not really have a recieve side access control since
> the are "send only". Also, for SIN/FIN/RST packets, since there is
> no data that comes to the application, the application did not
> really need to know about the socket options supplied. The app can find
> that out when it gets the first data packet at does access control
> stuff.
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.
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.
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.
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.)
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.
I hope I'm clearer this time.
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]
--------------------------------------------------------------------
