> On 05 Jun 2015, at 15:52, Michael Tuexen <michael.tue...@lurchi.franken.de> > wrote: > >> 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...
Exactly. I meant "important" as "to be discussed first" (hm, maybe simply "listed first in the doc"). I think it would make things easier and clearer to first discuss the things that are exposed by the abstract APIs today. SCTP will help, then: it exposes "reliable". So if we'd go with that, the first item in your list above for TCP would already disappear from the discussion: it will eventually need to be exposed by a TAPS system because of SCTP anyway, and thus belongs in the list. So if the document would, for instance, first list all the things that the protocol's abstract API now expose, and then follow with static properties that protocols have (and that a certain combination of chosen services would entail), then that list of static properties gets shorter - e.g., for TCP, from the two items above, only "byte stream" would be left. My aim here is to try to simplify things so that we can gradually make progress rather than beginning by discussing a long list where it's very hard to argue for why one particular bit should be in the list or not. If folks things I'm not making it easier but harder, please ignore me :-) I'm only trying to help... Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
