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 <[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
