>
>
> Surely the better direction would be to move towards what TCP does? We
> are fundamentally talking about TCP, so its methods and manners should
> dominate, no?
>
> Most discussions I have seen about the low level framing of TLS &
> friends indicate it is wildly complicated and overdone, and something to
> distance from in new designs, not emulate.
>
> (Although to be fair, I'm not really sure what this entails beyond the
> catch-all phrases of TLV & TCP. And, I'm not even sure I agree with
> imposing TLV over all of tcpinc. It opens the door to "flexibility" aka
> complexity, whereas tightness and purpose is better in my mind.)
>
Where you in the WG meeting (or listening in remotely)? My
understanding of the consensus in the room was that using TCP's
framing for tcpinc would make tcpinc too brittle in the face of
middleboxen which resegment the TCP connection (despite having let
the initial options through where we negotiated tcpinc on). Yes, we
all agree they those middleboxes shouldn't be doing that, but the
desire to make tcpinc continue to work through those sorts of boxes
mandates that we not use TCP's framing but do our own framing in-band
(within the bytestream carried by TCP). And the tcpcrypt folks
agreed to respin their proposal with in-band TLV-like framing.
-Tim Shepard
[email protected]
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
