Re: [tcpinc] AD review of tcp-eno

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Joe,

thanks for your feedback. See comments inline.

> Am 27.07.2017 um 16:25 schrieb 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.

We have actually assigned quite a couple of option numbers to experimental RFCs lately, given it is very common to go for experimental first in transport. As this work is chartered for experimental, we will go with IESG approval in this case, however, maybe we should consider to change the policy to "IESG Approval or RFC Required“ instead.

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

That’s right. I though RFC6994 would make a general recommendation here. But I guess it’s anyway good to add one sentence that implementations that following this specification should actually not respond to the experimental option. Thanks for noting.

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

While I know the problems with squatting that we have, I don’t think is a suitable option to enable good deployment for this or any new IETF protocols that we invested a lot of time in. I though we had this discussion already and concluded that the best viable option for this case is the number that they already squatted on. Let’s go for this path.

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

It does. The initiator must reset the connection in this case. It’s phrased slightly complicated but it is specified. Maybe this can be clarified a bit better/described earlier in the text.

Mirja


> 
> Joe