So... One of the things I have been trying to understand over the last couple of weeks is what entities we have to name in TAPS, and how we give the entities names that seem to be understood by our community and preferably are common with other uses in the IETF.
I came across one term that appears to be defined differently in the charter discussions, to how I would normally understand this. This email tries to explain this, if you think the same as me, please speak-up and say this, if you think another definition is better, please say why. I think the group just needs to decide at this stage, so that all actual RFCs that are made will be consistent. --- 1) Transport Service I see a "Transport Service" as an end-to-end service that has traditionally been mapped by transport people down to a "port/socket" (perhaps the "S" part of tsv). This appears consistent with other uses, I have come across. However, a service is usually composed of a number of "components" - I seem to recall these be called "service elements" in OSI. Examples are: reliability, multicast, confirmed delivery, congestion control, integrity, minimal latency, etc. (we could, and probably should make a list). Application | Transport Service(s) | | Service Service Component Component(s) Hence, I see a service as offered via an API to an App or upper-layer protocol. I see a service as having multiple components. This is not necessarily the usage in the final charter fro TAPS!! --- 2) When the charter says; "Four examples of Transport Services are reliable delivery, ordered delivery of data, content privacy to in-path devices, and minimal latency." - I think these could indeed be transport services, but I'd actually now suggest they could be better described as components/elements of a transport service. In my thinking, one could always build an entire service that was oriented at "minimal latency" - but equally one could conceive of this as a transport service component that could be combined with security, ordering, etc. (using the language above). --- 3) Transport Protocols Transport protocols are not a service, because many transport protocols can provide multiple services (again my own terminology). Indeed a single transport can negotiate to support multiple "features". A "feature" represents a choice of protocol mechanisms/parameters to instantiate a service (or one component of a service, e.g. use of ECN, optional integrity checks, etc). This term has been sued before, one of the older uses could be FTP feature negotiation. DCCP formally included "features" in its protocol design. Transport protocol | | Feature Feature(s) | Protocol mechanism(s) --- For anyone in fear this is endless, it is NOT going to be. Mirja will present slides to ask for confirmation of the hierarchy terms at the meeting next week, and after a <shot> discussion we plan to very quickly and publish a new revised ID with the WG-"approved" terms and use these hence-forth. Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
