First, I think this discussion would benefit from a clarification of
what "API" means, or at least to stop using that term in isolation.
There are three distinct concepts:
A- abstract protocol "upper layer interface"
e.g., OPEN, CLOSE, ABORT, as per RFC 793
B- programmer API
e.g., Linux C/C++ TCP socket interface
C- instance of a programmer API
e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface
IMO, this document MUST discuss A, and can be address potential
extensions to A based on examining variants of B and C.
There are also the protocol features, which are the properties of the
protocol that:
- can be explicitly configured and monitored
these are *exactly* A, B, and/or C above
- can be implicitly detected
some are based on the definition of the protocol,
such as reliable, byte sequence delivery
some are an artifact of the implementation,
such as specific delays due to burst losses
However, *none* of this is a rat-hole IF TAPS is intended to explain the
service interface to the user. IMO, B and C above should be secondary
considerations after A is clearly documented, but this draft is a long
way from that.
Joe
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
