> On 05 Jun 2015, at 11:05, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> 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. I consider "protecting against bit errors" a service. And I think the level is important. I agree, TCP and SCTP provide a protocol dependent level of protection, so there is no need to expose this in the API of the particular protocol, however, I do think someone wants a strong checksum or not, and that will influence the choice of protocols. So we do have services which are not configurable via the API.
Best regards Michael > > 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 _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
