> On 19 Jun 2015, at 14:32, Brian Trammell <i...@trammell.ch> wrote: > > hi Michael, > > continued, inline. > >> On 18 Jun 2015, at 18:44, Michael Welzl <mich...@ifi.uio.no> wrote: >> >> >>> On 18. jun. 2015, at 15.56, Mirja Kühlewind >>> <mirja.kuehlew...@tik.ee.ethz.ch> wrote: >>> >>> Hi Michael, >>> >>>> Am 18.06.2015 um 15:43 schrieb Michael Welzl <mich...@ifi.uio.no>: >>>> >>>> >>>>> On 18 Jun 2015, at 10:48, Mirja Kühlewind >>>>> <mirja.kuehlew...@tik.ee.ethz.ch> wrote: >>>>> >>>>> Hi Joe, >>>>> >>>>> I believe the approach Michael is proposing is to look at existing APIs >>>>> as a starting point; not only abstract APIs. >>>> >>>> No, wrong. Only abstract ones from RFCs, I said this before. These things >>>> would typically have preceding IETF debate, whereas trying to cover >>>> implementations is a huge and probably meaningless endeavour (the bar may >>>> be high for adding function calls to an API on system X and low for an API >>>> on system Y). >>> >>> Okay, but then I don’t really understand your approach fully. Yes we should >>> document and look at what’s already specified in RFC, however isn’t the >>> goal of taps to actually figure out how to change/extend/improve these >>> APIs? How can we figure out what’s missing/wrong if we only look at what’s >>> already there? >> >> *My* goal is, and has always been, to provide a simpler, general API that is >> protocol independent. > > +1, though I would at this point say "better" as opposed to "simpler" and > "general", with the caveat that i'm not yet sure what better looks like. This > gets back to my point about interaction patterns in the previous message, > though: if the simpler API provides only stream interaction, or packet > sequence interaction, or if it only allows receivers to get data through > asynchronous notifications, it will make it hard to support . So maybe we > want a better common API for defining the *requirements* of an association, > and better TX/RX *APIs* plural, one for each interaction pattern we want to > support.
I agree. >> Note that this is not only for simplicity for ease of use BUT also for the >> sake of being able to automatize. After all the major goal is to remove the >> strict binding between applications and a specific protocol choice. > > We share this higher level goal in any case. > >> To be able to do this (documents 2 and 3), we first need a list of the >> existing services - our toolbox, if you wish (document 1). Figuring out >> what's missing / wrong about today's APIs (except that they are bound to a >> specific protocol) has never been *my* major intention, and I certainly >> don't see that as the goal of this document. I'd be surprised if that's what >> the charter suggests?! But of course my opinion is only what it is, the >> charter reflects the consensus... > > I don't think that's in scope for this document, either. The component (and > decomposition) work is aimed at figuring out what the available features are, > and what (in a "TAPS as glue layer over existing transports" design) the > implications of using protocol X for feature Y are. The API work is a bit of > a non-sequitur (but also important to note...) > >> All this being said, it can be a nice side-effect of the document (and note >> that noone knows what a TAPS system will really look like, and how these >> RFCs will actually end up being used). > > In general, if there's any content in this document that is useful but > doesn't fit but we still find useful, we can certainly put it something else. > >> So I'm not strongly opposing the approach you're now following in that I >> don't see a big issue with there being a list of components - I just think >> it's not particularly useful for the goal of the document and doesn't really >> help the group progress towards its goals. I thought that proposing >> something more systematic with less arbitrariness could make it easier to >> put everyone in the same boat (in a way: "look, the boat HAS to be like >> that, there wasn't much choice, sit down please" rather than "sorry I >> painted it green, I like that color; I can understand you would have >> preferred a blue boat..."). > > I agree. Given, though, that the protocols we're looking at, that they > weren't designed from components, it is really not clear to me how to > systematically decompose existing protocols without making arbitrary choices > as to where to make the cut. but why decompose? > (and I wouldn't read too much into the approach we're following -- we're > trying to incorporate the input we've taken from discussion on the list into > the structure of the document, and as Mirja says, we're completely open to > trying other approaches to do that). > > We could take an opposite approach here: jump forward to section 4, define > the features we think we want -- this we can do more systematically, because > we're only limited by the intersection of the features we want and the > features we think we can realistically deploy, as opposed to the history > represented by the protocol components -- and then use the components as a > check on the feasibility of those features. Interesting idea - it sounds good to me! Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
