On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
> 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.
To be clear, can you clarify the focus?:
- what IS/IS NOT (i.e., current requirements)
- what WILL BE/WILL NOT BE (i.e., future goals)
AFAICT, this is about IS/IS NOT. With that in mind, it should not be
necessary to "collect data" and then decide later what is exposed or not.
> 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.
There seems to be ample confusion about:
- upper layer interface (abstract "API"): services to the user
- lower layer interface: services needed from the next protocol layer
- the protocol itself (as an abstract specification: i.e., the finite
state machine rules that relate commands and responses to the ULI, calls
and returns to the LLI, and internal state and events (e.g., timers)
- the *implementation* of any of the above, e.g.:
- Unix sockets API
- interface to IPv4
- Differences that include Reno vs. Cubic..., MTU algs, etc.
> However, features in
> contrast should really only be the things that should be exposed.
IMO, implementation issues should be fully out of scope.
> 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.
Frankly, RFC 793 specified exactly what is needed here (it may need to
be augmented with options and later extensions), but that needs to be a
*starting point* for these discussions.
And the current doc doesn't come close to what's in 793.
If we're not starting there, there's little point in starting IMO.
Joe
> Mirja
>
>
>> Am 27.05.2015 um 00:36 schrieb Joe Touch <to...@isi.edu>:
>>
>> 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
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
