> >> Another approach here would be to make it easy for other RFC authors > to > >> leverage tcpcrypt to protect the privacy of there options. For any > >> options that are tied to data, moving them in-band to special TLV > >> frames > >> might make the most sense. > > > > Formally, that would require a proposed standard specification of > > TCPINC because only then it can be used in standards produced by > other > > working groups such TCPM. And I believe we are here discussing a > > mechanism that may have to update RFC 793, which is an Internet > > Standard that is ubiquitously deployed in the Internet. > > First, I'm fine with not further discussing as you suggest. However, > IANA does assign TCP option kinds to experimental RFCs (e.g., RFC6824, > with option kind 30 for multipath TCP, and I hope one day TCP-ENO as > well). So I hope it's not completely unreasonable to imagine future > experimental RFCs that use TCP options to say something about tcpcrypt.
In this context, I want to mention once again that in my point of view the TCP-ENO specification should use RFC 6994 right now: https://www.ietf.org/mail-archive/web/tcpinc/current/msg00815.html https://www.ietf.org/mail-archive/web/tcpinc/current/msg00817.html I'd like to explicitly thank for ignoring my feedback. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
