I took a closer look at the API document just now. The first thing that jumps out at me is that since you are already providing part of a socket interface (via getsockopt/setsockopt), it may be helpful for interoperability to specify the errno values to be associated with particular protocol-level failure modes. E.g., if the application tries to set TCPENO_TIEBREAKER to 2, setsockopt should report EINVAL.
The section on automatic configuration may be useful, but is the strategy outlined based either on data on general interference with TCP traffic by middle boxes or on empirical investigation of TCP-ENO itself across various types of networks? I'm also assuming that if HMAC is an example of a PRF that the first argument to PRF is the key material. Not sure whether this needs to be spelled out. Kyle On Mon, Aug 10, 2015 at 8:45 AM, David Mazieres <[email protected]> wrote: > We have revised the TCP-ENO draft and posted a new version that > addresses feedback we have received so far. The biggest change we made > was to split the document in two. TCP-ENO itself specified is specified > in an experimental status document, as before: > > * https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/ > > The API changes are now specified in a new informational status document > that could potentially form the basis of the working group's API > document if people like it: > > * https://datatracker.ietf.org/doc/draft-bittau-tcpinc-api/ > > We'd appreciate feedback on these two new drafts. > > Thanks, > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
