Hi Joe > > My concern is that there is no clear relation between 3.1.2 and 3.1.3.
Yes, that’s actually true. Initially there was no section 3.1.2 as this doc is not on interfaces. However it seems to be incomplete without mentioning interfaces at all. If we keep this section, you are right, the relation should be there. > > In fact, many of the properties of 3.1.3 are the result of the interface > mentioned in 3.1.2. Really? Can you give an example? I would rather hope that we can describe the transport components independent of the currently/any interface. > Also, a few aspects of the 3.1.2 interface aren't > considered in 3.1.3. To complete 3.1.3, looking at interface is probably useful. Can you list what’s missing? > > So what's the point of 3.1.3? I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a list of components as basis for discuss which features should/must be exposed to the app-layer. > >> From the definition: > Transport Protocol Component: an implementation of a transport > service feature within a protocol. > > Unfortunately, the items in 3.1.3 aren't implementations; they're > general properties. An implementation would be Reno or CUBIC. I agree that what’s currently listed is not on the right level of detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on the right level either. Maybe it’s delay/loos-based or foreground/background or AIMD, but congestion control is especially complicated I’d say. That’s what we have to figure out now. > > In addition, API isn't defined (e.g., see my previous 3 descriptions), > so it's never clear what should be in 3.1.2 (or the corresponding > sections of other protocols). I don’t know either what should be in 3.1.2 right now. Anything that is useful for 3.1.3 or 4 should be mentioned; everything else will be removed at the end (potentially even the whole section). > > As a result, I do not understand the purpose of either section of this > document, or this document as a whole. That’s to bad. Maybe we should state this more explicitly in the intro…? According to our charter, while taps itself is chartered to describe "an (abstract) interface for applications to make use of Transport Services“, this first document is only used to "identifying the [components] provided by existing IETF protocols“ as a starting point. Further we would like to add some discussion in section 4 which of the identified components should/can be exposed as a transport feature that the app should see. [Note that the terminology changed and whenever services is written in the charter it should basically be component.] Does this help? Mirja > > Joe > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
