Re: [tcpinc] AD review of tcp-eno

[Joe Touch <[e-mail]>]

On 7/27/2017 6:14 AM, Mirja Kuehlewind (IETF) wrote:
> ...
>> I’m afraid we need a new revision before IETF Last Call because the RFC should only specify the actually TCP option and not the experimental one. So you can simply remove the experimental one in Figure 1, 2 and 3 (as well as sec 4.8) and only note in the IANA section that this experimental assignment also exists, as it is already done.
First, as an Experimental RFC, I don't think it would be appropriate to
assign a codepoint that requires a standards-track doc.

Second, regardless of whether the IESG decides to override that
requirement, this document needs to address how to handle packets with
the ExID values that have already been assigned if they are considered
to be part of the transition plan (though it would be better to describe
a transition plan). Per RFC6994, the authors do need to address this
issue, especially indicating that connections should *not* include both
variants in the same segment.

Finally, IMO, if a TCP option codepoint is assigned, I strongly
recommend not poisoning the codepoint space with a "fresh" assignment,
nor should the developers be rewarded for squatting on a value. The only
appropriate solution IMO, in that case, would be to assign this option
to a codepoint already squatted **by another party**. In that case,
their deployment would appropriately suffer from the impact of squatting.

>> Other minor comments:
...
>> 2) I’m wondering if it would make sense to specify at the beginning of section 4.7 another requirement that TEPs SHOULD only specify the use of SYN data if there is some a-priori knowledge that the other end is likely to support tcp-eno and the tep (e.g. due to previous successful connections aka session resumption, or application knowledge).
That section does not appear to address the case where non-user data in
the SYN is received by a legacy receiver, either because of first
contact or in contacting a host that has changed configuration since
last contact. In such cases, there is no way to support transparent
fallback as required by RFC 1122 -- which is why it is avoided at all
costs. AFAICT, this optimization is too hazardous to include at all.

Joe