Re: [tcpinc] AD review of tcp-eno

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

Resending because I just realized I forgot to cc the list…

> Am 26.07.2017 um 19:06 schrieb Mirja Kühlewind <[e-mail]>:
> 
> Hi all,
> 
> thanks for this very well written document and detailed shepherd write-up!
> 
> 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.
> 
> Other minor comments:
> 
> 1) I would recommend to switch the last to paragraphs in section 4.5; I think that helps understanding.
> 
> 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).
> 
> 3) Sec 4.8 does not really specify what to do with the transcript. I guess that’s TEP specific but it sounds like there should be a requirement stated that a TEP has to check this or abort the connection…?
> 
> 4) sec 5:
> s/TEPs MUST protect TCP data streams with authenticated encryption./TEPs MUST protect TCP data streams with unauthenticated encryption./ ? Or do you mean must support both, authenticated and unauthenticated?
> 
> 5) section 6: Maybe
> OLD
> "Figure 9 shows a three-way handshake with a successful TCP-ENO
>   negotiation.  The two sides agree to follow the TEP identified by
>   suboption Y.“
> NEW
> "Figure 9 shows a three-way handshake with a successful TCP-ENO
>   negotiation. Host A includes two ENO suboptions with TEP identifiers X and Y. 
>   The two sides agree to follow the TEP identified by suboption Y.“ 
> 
> 6) Also looking at the example in Figure 11, I have to say that the spec does not clearly state anywhere that the first ACK has to have a ENO option (it’s only mention implicitly somewhere). Maybe that can be spelled out more clearly (in section 4.6)?
> 
> 7) Also based on this example. I guess it’s also possible that a middlebox does not strip the options in the SYN packets but only in the ACK. In this case host A would send encrypted data and host B would think they are not encrypted and deliver garbage to the application. I’m not sure how to avoid or even detect such a case but maybe it’s still good to mention this somewhere…?
> 
> 8) section 7.2: The following is a normative requirement thats should be stated normatively (MUST) somewhere in the main part of the specification:
> "To stay robust in the face of dropped segments, hosts must continue
>   to include non-SYN form ENO options in segments until such point as
>   they have received a non-SYN segment from the other side.“
> 
> 9) I would recommend to move 7.1 into an own section (not as part of section 7 on rational), or maybe rather as a subsection of section 8.
> 
> 10) From reading the text in the IANA section, I believe you rather what „RFC required“ as a policy (see https://tools.ietf.org/html/rfc8126#section-4.7). Early allocation are always possible and does not need to be noted separately (see https://tools.ietf.org/html/rfc8126#section-3.4).
> 
> 11) Do you want to specially note Andrea’s contribution to this work in the acknowledgements?
> 
> 12) RFC5226 (now RFC8126), RFC6994 (after removing the exp option from the body of the doc), and RFC7413 do not need to be normative references. Please move to informative.
> 
> 12) Finally, two tiny things from the nits check:
> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tcpinc-tcpeno-08.txt
> - There shouldn’t be reference in the abstract. You can just remove it; TLS is well known. You may want to add it in section 7.1 instead.
> - RFC 5226 is obsolete
> Both could be fixed by the editor but as you anyway have to make a new revision, so you can fix these as well.
> 
> Thanks!
> Mirja
> 
>