Found 1 record.

Status: Reported (1)

RFC 9174, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", January 2022

Errata ID: 8770
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Brian Sipos
Date Reported: 2026-02-19

Section 5.2.2. says:

Once a transfer of a bundle has commenced, the entity MUST only send
segments containing sequential portions of that bundle until it sends
a segment with the END flag set to 1.

It should say:

Once a transfer of a bundle has commenced, the entity MUST only send
segments containing sequential portions of that bundle until it sends
a segment with the END flag set to 1 or until the sender chooses to
cancel the transfer.

Upon reception of a data segment containing a new Transfer ID before
reception of a data segment with the END flag set for any other
earlier Transfer ID, the receiving entity SHALL consider the earlier
Transfer to have failed. The failure of an individual transfer due to
missed data segment with END flag set SHOULD NOT cause the receiver to
terminate the TCPCL session.

Notes:

There was no specific mechanism for a sender to cancel a transfer after it has started. For large bundle PDUs this is a large commitment by the sender which could only be resolved by finishing the transfer or performing an unclean session termination, possibly interrupting transfers in the other direction in the same session. While this mechanism of transfer cancelation is not ideal because it is implied from the lack of messaging, presumably the reason why the sending entity chooses to cancel a transfer without terminating the session is that there are subsequent transfers needing to be sent. It is still completely valid and backward-compatible for an entity to simply never cancel a transfer.

Separately, there was no requirement on how a receiver needs to handle this case of a transfer simply having no more data segments received but still seeing other messages received.

Report New Errata