On 4/5/2017 2:23 PM, Michael Welzl wrote: >> 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? Having a "window" into what TCP is doing is nice, but not necessary.
Having a way to disable Nagle (or enable it, for that matter) is necessary. I'd draw the line at "required" to make TCP work correctly. > 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. IMO, it's hard to scrub those RFCs for this info. There was a time when the IETF decided that APIs were out of scope and a lot of the info you need was ignored in RFCs, or at best pushed to "honorable mention". > 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. I don't know what the requirements are for a minimal TCP system, so there's no way to answer that. We ought to understand that for every protocol we design, but we don't. >>> 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! AOK. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
