> On 5. jun. 2015, at 10.12, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > wrote: > > Okay, just to quickly clarify. In the charter only the word service is used. > We defined later on the words component and feature which are currently not > reflected in the charter. The part I've cited below, I think, it should say > components. However, it does not really matter because we will in the current > document first identify components and then discuss features. In any case > this document will not define a new interface.
I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... > I'd also say that this is not the flag ship document (as stated by Joe). The > flagship document probably is the third item on the charter which then will > probably also talk about the interface in more detail (charter says on the > third doc: "This document will explain how to select and engage an > appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. That's why I think the service is more important than the component, and that's why I'm on Joe's side here. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
