Hi Joe,

I agree. This is a working document and we are still in the phase of collecting 
data while the next step is to discuss which things that are currently listed 
must/should be listed or not and also which of the things must/should be 
exposed to the app.

However, I think we are on the write track for the TSC because these are thing 
that are implemented independent of the question if these things should be 
exposed to the app or not. However, features in contrast should really only be 
the things that should be exposed. The list in section 4 currently copies 
everything from above and we need to have the discuss now what should stay 
there and what not. 

Mirja


> Am 27.05.2015 um 00:36 schrieb Joe Touch <[email protected]>:
> 
> 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

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to