> On Apr 5, 2017, at 11:31 PM, Joe Touch <[email protected]> wrote: > > > > 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.
Yes - >> 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. I don’t think the group ever agreed on any - so my statement was based on our (authors’) own rules, laid out in: https://tools.ietf.org/html/draft-gjessing-taps-minset <https://tools.ietf.org/html/draft-gjessing-taps-minset> > 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 Thanks! Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
