Jinmei Since you are soliciting comments from implementors, here are my opionions about the change ( I was going to wait until I got to work).
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. Before I say any more, I would really like to know the reason why you think the change is needed. -vlad JINMEI Tatuya / 神明達哉 wrote: > > >>>>> On Thu, 13 Dec 2001 11:19:40 +0900, > >>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said: > > >> An alternative candidate is to allow the stack to pass ancillary data > >> items even without TCP data (recvmsg() would then return 0 in such a > >> case.) With this approach, however, the application may not be able > >> to determine the termination of a connection. The traditional coding > >> style like > > (snip) > > > So, apart from the impact on the socket semantics, this is a migration > > (or backward compatibility) issue. I'd like to know the current > > situation about the deployment of rfc2292bis-02 (or before), and > > opinions of implementors that have implemented or have a plan to > > implement RFC2292 and/or rfc2292bis. > > As I said in the today's meeting, please speak up about your opinions, > if you're interested in implementing the API. I'd like to collect the > opinions, and will soon revise the draft based on consensus. > > Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] > > p.s. since I skipped some topics in the presentation, I've put the > presentation slides at the following URL. > > http://www.kame.net/~jinmei/mgp/ietf52-advapi/ > > Please refer to the web version of the slides if necessary. > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
