+1 with WG chair hat on - I think Joe's text sets the right expectation. Thanks, --David
> -----Original Message----- > From: Tcpinc [mailto:tcpinc-boun...@ietf.org] On Behalf Of Scharf, Michael > (Nokia - DE) > Sent: Tuesday, February 07, 2017 1:54 AM > To: Joe Touch; David Mazieres expires 2017-05-06 PDT; Holland, Jake; > tcpinc@ietf.org > Cc: t...@ietf.org > Subject: Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno > > I'd agree to Joe's proposal "Although this protocol could benefit from > extended > SYN space, e.g., to support in-band key coordination, future TEPs should > expect > to use only the currently available space." > > Michael (chair hat off) > > ________________________________________ > From: Joe Touch <to...@isi.edu> > Sent: Monday, February 6, 2017 17:34 > To: David Mazieres expires 2017-05-06 PDT; Scharf, Michael (Nokia - DE); > Holland, > Jake; tcpinc@ietf.org > Cc: t...@ietf.org > Subject: Re: [tcpm] [tcpinc] WGLC for draft-ietf-tcpinc-tcpeno > > FWIW: > > > On 2/5/2017 5:26 AM, David Mazieres wrote: > > "Scharf, Michael (Nokia - DE)" <michael.sch...@nokia.com> writes: > > > >> While TCPM discusses large SYN options (for a long time already), all > >> known solutions have downsides. I do not believe that a non-TCPM > >> document should speculate on the feasibility solutions. > > Michael, what do you think of the new proposed wording? > > > > Various proposals exist to increase the maximum space for options in > > the TCP header. Though these proposals are highly experimental-- > The non-SYN extension is currently a WG document and intended for > standards-track. > > particularly those that apply to SYN segments > The SYN extension proposals all have significant known issues and are > both highly experimental and difficult to deploy. > > > --TCP-layer encryption > > could significantly benefit from the availability of increased SYN > > option space. > It might be useful to differentiate between the potential use of non-SYN > vs. SYN space. > > You should be more explicit that "Although this protocol could benefit > from extended SYN space, e.g., to support in-band key coordination, > future TEPs should expect to use only the currently available space." > > IMO, the following is speculative and not useful: > > > In particular, if future TEPs can perform key > > agreement by embedding public keys or Diffie-Hellman parameters > > within suboption data, it will simplify protocols and reduce the > > number of round trips required for connection setup. With large > > options, the 32-byte limit on length bytes could prove insufficient. > > This draft intentionally aborts TCP-ENO if a length byte is followed > > by an octet in the range 0x00-0x9f. > The following appears to direct TCPM docs to update this doc, which is > not appropriate. If there is a SYN extension, it is much more likely to > be a stand-alone doc to update RFC793 and other docs would individually > update protocols that might benefit from that space. > > > Any document updating TCP's > > option size limit can also define the format of larger suboptions by > > updating this draft to assign meaning to such currently undefined > > byte sequences. > > ... > > > > Our goal is not to second-guess TCPM, but rather to provide TCPM with a > > data point that they have a "customer" for large SYN options in the > > unlikely event that some proposal is ever deemed realistic. I could > > make the wording even stronger, as in: > > > > These proposals are highly experimental--with those that apply to SYN > > segments particularly unlikely to be adopted any time soon--but > > TCP-layer encryption could significantly benefit from the > > availability of increased SYN option space. > Actually, the above is much more useful (IMO), but most of the rest of > the paragraph can be omitted. > > Joe > > > > > But that could be seen as second-guessing TCPM in the other > > direction--telling TCPM we *don't* expect them to standardize large SYN > > options anytime soon. (Of course, it's true that I don't expect them to > > do that, but it might not be my place to say so in an RFC unless you > > sign off on the language...) > > > > As always, concrete suggestions on wording are appreciated. > > > > Thanks, > > David > > > > _______________________________________________ > > tcpm mailing list > > t...@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > Tcpinc mailing list > Tcpinc@ietf.org > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
