> On 05 Jun 2015, at 13:29, Mirja Kühlewind <[email protected]> > wrote: > > Hi Michael, > > see below. > > > On 05.06.2015 11:05, Michael Welzl 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 don't think that this decision is (in general) that easy. That's why we go > through the exercise of decomposing existing protocols into their components > and based on this information discuss what potentially could be exposed and > further reason about what should be exposed (because there are implications > for the application). > > From my point of view this process it independent of the interface (not > matter if we talk about an abstract interface, a certain implementation or > what we want to have in future). However, looking at current interfaces will > probably help us to make the right decisions. > >> >> >>> 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. > > I didn't say anything about the importance of anything. I think all three > documents and and all kind of transport 'things' we talk about are important. > And most important is the process of getting things 'decomposed' correctly > and discussed in the right document at the right time. > > What I wanted to say is that people who later on read these docs (because > they want to use taps), probably only read the third doc, maybe the second, > and very likely will only read this document if they already have read the > other two and would like have additional information. > > I do have the feeling that parts of what Joe wants to discuss should however > be in the third doc. And therefore I think that the current first doc is not > the taps flagship doc because for me a flagship doc (and we probably need to > define this term ;-) ) is the doc that you point people to as the first thing > to read after the work was finished...? > > All in all, I actually think that we are on the same side here (and right at > this point we don't need too much further discussion). Brian and I are in the > process of marking a better distinction on components and feature than what > is given in the lists in the current version. I believe the current, very > sloppy handing of these lists is where most on the confusion (and potentially > disagreement) comes from and I hope that discussion can be more focused soon > as we have submitted the next revision.
Cool, thanks for the work you folks put into this! And have a nice weekend, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
