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 Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps