"Mirja Kuehlewind (IETF)" <i...@kuehlewind.net> writes:
> Yes, it’s better. It doesn't redefines what to do with the FIN, so
> that’s good. For the first sentence it now sounds like this is
> independent of the FIN in the regular TCP. Is there a reason why you
> don’t want to go for a phrasing as I proposed where you say something
> like if TCP would set the FIN (as defined in RFC793) you also have to
> set the FINp?
Daniel and I discussed this, and our feeling is that even though FIN and
FINp have similar names and a related purpose (it's fair to say the FINp
bit protects the TCP FIN bit), it was actually more confusing to try to
explain their roles together. In particular, the end of a TCP
connection could involve a TCP segment containing multiple tcpcrypt
frames, or a tcpcrypt encryption frame that spans multiple TCP segments.
So one could go down some complicated bifurcating analysis of what to do
in all cases, or just say set FINp on the last frame which seemed both
intuitive and correct.
We could add one sentence about what TCP does with FIN to say something
like the following:
A sender MUST set the `FINp` bit on the last frame it sends in
the connection (unless it aborts the connection), and MUST NOT
set `FINp` on any other frame.
TCP sets the `FIN` flag when a sender has no more data, which
with tcpcrypt means setting `FIN` on the segment containing the
last byte of the last frame. However, a receiver MUST report
the end-of-file condition to the connection's local user when
and only when it receives a frame with the `FINp` bit set. If a
host receives a segment with the TCP FIN flag set but the
received datastream including this segment does not contain a
frame with `FINp` set, the host SHOULD abort the connection and
raise an error condition distinct from the end-of-file
condition; if there are unacknowledged segments whose
retransmission could potentially result in a valid frame, the
host MAY instead drop the segment with the TCP FIN flag set.
This is maybe a bit pedantic/redundant, but potentially clearer. Do you
prefer this proposed language?
David
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
