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