FWIW, the current setsockopt commands are an extension (IMO) of the STATUS command of RFC 793, allowing it to not only read connection information but also modify it.
IMO, we should think of it in those terms, not merely "setsockopt" or "ioctl" or anything else. Joe On 4/5/2017 12:46 PM, Michael Welzl wrote: >> On Apr 5, 2017, at 9:31 PM, Joe Touch <[email protected]> wrote: >> >> >> >> On 4/5/2017 12:12 PM, Michael Welzl wrote: >>> Hi, >>> >>> Thanks a lot for checking this! >>> >>> >>>> On Apr 5, 2017, at 8:01 PM, Joe Touch <[email protected]> wrote: >>>> >>>> >>>> >>>> On 4/5/2017 5:45 AM, Michael Welzl wrote: >>>>> This is the minor change that I promised at the last meeting - mainly to >>>>> include TCP Authentication (RFC 5925). >>>> There are bugs in the description. TCP-AO was careful to say "TCP SEND, >>>> or a sequence of commands resulting in a SEND" (same for RECEIVE), >>>> regarding setting or viewing received key IDs (current and next), >>> Hm, I saw this but didn’t get it - what is “a sequence of commands >>> resulting in a SEND” (or RECEIVE) ? >>> I just don’t get what that’s supposed to mean. E.g., what else than SEND >>> will send? >> E.g., setting a socket option to set values then using SEND, or RECEIVE >> then socket options to read. >> >> The point was that the setting of those values can be asynchronous to >> the SEND/RECEIVE calls. > Okay, got it; socket options don’t exist in RFC 793 language, or any of the > RFCs updating it, I think… > maybe this RFC should have invented such a function call? Anyway, I can do > this for you :-) to some degree, that’s the role of my draft. I can say > that RFC 5925 demands this functionality, and describe SET_AUTH and GET_AUTH > primitives that would map to that. > > >>>> especially including ways to set/read these values even when a SEND or >>>> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). >>> I also saw this but didn’t see it as mandatory to provide (“It may be >>> useful…”, the text says). Is this really very useful? >> You might want/need to change keys on a BGP session even when you aren't >> yet ready to issue a SEND. You might want to check to see of the keys >> have changed due to retransmissions or ACKs even when you didn't issue a >> RECEIVE. > Okay… > > >>>> I didn't give a deep re-read and I don't recall from my earlier checks, >>>> but is there a discussion of using other operations to interact with >>>> connection parameters (socket options, ioctls), e.g., as part of the >>>> required interface? >>> Nothing that’s not in the RFCs… I did rephrase the authentication stuff for >>> TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating >>> that they’d be implemented using SEND and RECV. Not much else available… >>> >>> If you say it’s important it can be added, I guess, but I find it hard to >>> derive that from the text in RFC 5925. Well, empty send’s and receive’s are >>> a way out, I suppose. >> It's not just RFC 5925. The issue is whether there are other mandatory >> configurations or monitoring that is async to SEND/RECEIVE. If so, then >> you can't simply assume they occur only during those calls. > There isn’t much; Nagle is an example - RFC 1122 just says that the > functionality to enable / disable must be there, without specifying via which > primitive that would happen. > So, my draft says, in pass 2: > > o DISABLE_NAGLE.TCP: > Pass 1 primitive / event: not specified > > Seems like I should do the same for set_auth and get_auth. > > Cheers, > Michael > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
