> On Apr 5, 2017, at 10:33 PM, Joe Touch <[email protected]> wrote: > > Hi, Michael, > > > On 4/5/2017 1:10 PM, Michael Welzl wrote: >>> On Apr 5, 2017, at 9:55 PM, Joe Touch <[email protected]> wrote: >>> ... >>> Set_auth and get_auth are either in the STATUS (as per my previous >>> message) or SEND/RECEIVE. >> What’s the problem with defining new primitives for these things? It’s just >> an abstract API anyway. > You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., it > does say that the management of these parameters can be via > SEND/RECEIVE, but doesn't have to be.
We seem to agree: see below - >> I actually removed STATUS in my draft because of the following reasoning >> (quoting my own draft): >> >> *** >> The 'status' primitive was not included because [RFC0793] describes this >> primitive as >> "implementation dependent" and states that it "could be excluded without >> adverse effect”. > > That was true back when 793 was created, but hasn't been true > effectively since 1122. Hmmm…. what about the whole block defined in RFC793? It tells you about rwnd, snd wnd, and strange stuff like security/compartment… where to draw the line? I guess by knowing what is actually happening in OS’es out there, for each of these items. That’s the quest I wasn’t going to take - this draft is based on the RFCs. I’d also say that these things don’t matter much for a (minimal) TAPS system - for many of these things, exposing them creates an unnecessary dependency on the protocol. >> Moreover, while a data block containing specific information is described, >> it is also stated >> that not all of this information may always be available. >> *** >> >> Because a TAPS system should be able to rely on things that are available >> pretty much everywhere, >> this draft doesn’t include things that are optional for an underlying >> transport to implement. > Agreed - I'm saying that there MUST be a command by which some > parameters of a connection can be monitored and altered after the > connection is established but asynchronously from a SEND/RECEIVE call. > > You might say that you could accomplish the result with a zero-byte SEND > or nonblocking RECEIVE, but that's ugly from an API viewpoint. Agree to both - >>> There may be other signals that need to be specified. E.g., RFC1122 has >>> a few items that need to be indicated, but isn't clear about them being >>> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4). >> Exactly my point - disabling Nagle is one of these things. So I gave them >> names and call them primitives under “CONNECTION.MAINTENANCE”. >> Shouldn’t matter, as long as the functionality is there? > > Oh, OK - then you would want to say that the keyID and nextkeyIDs fall > under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. Exactly. Right now, the error is that the CONNECTION.MAINTENANCE primitive description says that this uses ‘send’ or ‘receive’. It shouldn’t. I’ll note that for the next update (when I'll address more comments from WGLC), thanks! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
