> On 19 Jun 2015, at 14:03, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > wrote: > > Hi Michael, > >> *My* goal is, and has always been, to provide a simpler, general API that is >> protocol independent. 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. > > Yes, I agree! (not sure if this is simpler though… depends on the definition > of simple… but hopefully easier to use and understand for the overlying > application).
Agree too, easier to use is what I meant >> 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… > > So there current API is always bound to a specify protocol which already > provides you a certain set of service feature. At least in TCP there is not > much choice left and there the current API does not give us a good indication > which services are actually provided by TCP. Therefore from my point of view > the only way to identify these services is to look at the protocol itself and > not only the API. In SCTP it’s different and we definitely have to and will > discuss the existing API in the document. Exactly that's why I thought starting with TCP's API (even when it's the abstract one) is not very helpful. Joe, Aaron: what is it you were expecting us to take away from reading section 3.8 of RFC 793? ( I can see it highlighting the need to discuss communication patterns (or decide for a specific one) in document #2, but not really contributing much to the list in document #1 ? ) >> 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). 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 totally understand this point. But at least for TCP I think it is not > sufficient to look at the (abstract) API because in TCP there are not much > choices and therefore the services TCP provides are not exposed over the API. > I personally currently don’t see how another approach would bring us the the > goal of identify existing services. Agree about TCP > Again, if you have time to work on an alternative approach, please go ahead > and provide input or even submit an own draft and I’m/we’re really open to > discuss this and see what makes more sense. Ok.... well, I agree that what I request is easier said than done :-( myself, I've been working on a first version of document #2 as I think this would help us understand if the set of "services" or whatever we call them in document #1 is useful for the group's purpose. Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
