> On 05 Jun 2015, at 12:35, Michael Tuexen <[email protected]> > wrote: > >> On 05 Jun 2015, at 11:05, Michael Welzl <[email protected]> wrote: >> >> >>> On 5. jun. 2015, at 10.12, Mirja Kühlewind >>> <[email protected]> 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.
Just for clarification: this wasn't about whether the level of "protection against bit errors" as such is important or not: I think the level of protection is a less important item to cover in the first document because, given current protocols (what this doc is about), you can't just switch it on or off - it comes with a choice of a whole protocol. So it's just a part of a protocol description - static protocol properties that come as a whole whenever you pick the protocol. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
