> On 05 Jun 2015, at 15:39, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> On 05 Jun 2015, at 12:35, Michael Tuexen <michael.tue...@lurchi.franken.de> >> wrote: >> >>> 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. > > 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. Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come with choosing TCP...
Best regards Michael > > Cheers, > Michael > > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
