Re: [tcpinc] Revised version of TCP-ENO

My comments so far:

> Once the two sides have exchanged SYN segments, the _negotiated spec_
> is the first valid spec identifier in the SYN segment of host B (that
> is, the passive opener in the absence of simultaneous open).  In
> other words, the order of suboptions in host B's SYN segment
> determines spec priority, while the order of suboptions in host A's
> SYN segment has no effect.  Hosts must disable TCP-ENO if there is no
> valid spec in host B's SYN segment.

> When possible, host B SHOULD send only one spec identifier (suboption
> in the range 0x20-0xff), and SHOULD ensure this option is valid.
> However, sending a single valid spec identifier is not required, as
> doing so could be impractical in some cases, such as simultaneous
> open or library-level implementations that can only provide a static
> TCP-ENO option to the kernel.

What is the meaning of "first valid spec identifier"? This allowance
for multiple spec identifiers sent by host B makes sense if the chosen
spec is "the first spec identifier also among those spec identifiers
that host A sent", but otherwise there's no difference between host B
sending a single static identifier or multiple: if host A supports the
first in host B's static list, that would get used; otherwise TCP-ENO
negotiation would fail.

You seem to imply the meaning above in figure 8, in which case I think
the text should be clarified.

3.3:

> A TCP segment MUST
> include at most one suboption whose high nibble is 0.

Does this mean "A TCP SYN segment including the TCP-ENO option MUST..."?

4.1: Do you want to add the additional requirement that session IDs be
public, i.e., not be secret to endpoints/applications?

Kyle

On Mon, Aug 10, 2015 at 8:45 AM, David Mazieres
<dm-list-tcpcrypt@scs.stanford.edu> 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
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc