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? > 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? > 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. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
