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