Hi, Brian (et al.),
On 5/26/2015 6:25 AM, Brian Trammell wrote:
...
> (3) frontmatter in Section 4 normalizing and categorizing the
> transport protocol components; please review this and suggest necessary
> or useful changes for using this as background for selecting taps features.
I like the definitions but IMO the protocol descriptions don't follow
the definitions.
I.e., I agree that a transport protocol service (TPS) is a feature or
capability made available to the app, and that a transport protocol
component (TPC) is an implementation of such a feature.
I realize I sound like a broken record, but the descriptions of the
protocols herein still does not match the definition of TPS or TPC.
E.g., for TCP, none of the following is exposed to the user:
- segmentation
- flow control
- congestion control
- error detection
At best, the effects of the above are exposed to the user in very
indirect fashion, certainly not as a "service" that can be used.
In addition, TCP provides all of the following services (the latter two
depending on being supported), which are not listed:
- PUSH
- URG
- authentication (via TCP-AO or legacy TCP MD5)
- control over user timeout (UTO option)
This continues to be a pervasive issue in this doc, i.e., not just for
this protocol.
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
