+1
David,
My view is that this document has to change significantly before we
can discuss adoption. Since this proposal significantly modifies the
TCP protocol and the TCP state engine, I'd really prefer to *first*
have a consistent document and *then* discuss a potential adoption.
If
the consensus in TCPINC is not to use header protection, I think
header protection has to be removed entirely from the protocol
specification - it could go to a separate document.
Hi, Michael. I'd like to address some of your points, and attempt to
provide and request clarification on others. So long as tcpcrypt is a
viable contender, we will of course produce an updated draft to disable
default header protection.
I digreee that disabling is the right approach. My suggestion is to entirely
remove all discussion of header protection from draft-bittau-tcpinc-tcpcrypt,
so that it is clear how a TCPINC protocol looks like without header protection
(if draft-bittau-tcpinc-tcpcrypt was used as a base protocol for TCPINC).
Header protection can go do a separate document.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
