RFC Errata
Found 9 records.
Status: Verified (3)
RFC 9171, "Bundle Protocol Version 7", January 2022
Note: This RFC has been updated by RFC 9713, RFC 9758
Source of RFC: dtn (int)
Errata ID: 8043
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Huff
Date Reported: 2024-07-22
Verifier Name: Erik Kline
Date Verified: 2025-08-11
Section 4.3.1 says:
CRC: A CRC SHALL be present in the primary block unless the bundle
includes a BPSec Block Integrity Block [BPSEC] whose target is the
primary block, in which case a CRC MAY be present in the primary
block. The length and nature of the CRC SHALL be as indicated by
the CRC type. The CRC SHALL be computed over the concatenation of
all bytes (including CBOR "break" characters) of the primary block
including the CRC field itself, which, for this purpose, SHALL be
temporarily populated with all bytes set to zero.
It should say:
CRC: A CRC SHALL be present in the primary block unless the bundle
includes a BPSec Block Integrity Block [BPSEC] whose target is the
primary block, in which case a CRC MAY be present in the primary
block. The length and nature of the CRC SHALL be as indicated by
the CRC type. The CRC SHALL be computed over the concatenation of
all bytes (including CBOR "break" characters) of the primary block
including the CRC field itself, which, for this purpose, SHALL be
temporarily populated with all value bytes set to zero. The
initial byte of the CBOR encoded CRC field SHALL remain unchanged.
Notes:
There was some confusion about the wording of "temporarily populated with all bytes set to zero" when talking about the CRC field in the CBOR encoded primary block. An implementer thought this might mean to also zeroize the intial byte(s) of the CBOR encoded byte string that represents the CRC field. This correction makes it clear that only the bytes that represent the value of the CRC field should be zeroized when calculating the CRC.
My correction uses "initial byte" because the current CRC types will only ever have a single intial byte when encoding the CRC value as a CBOR byte string. However, technically CBOR byte strings can byte more than 1 initial byte so it may be better to use "initial byte(s)".
--- see also ---
* https://mailarchive.ietf.org/arch/msg/dtn/3JAFDy9xJXIZNOItbnoqXkjlons/
Errata ID: 8525
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Huiung Park
Date Reported: 2025-08-05
Verifier Name: Erik Kline
Date Verified: 2025-08-10
Section 6.1.1 says:
as described in Section 4.2.5.1.1.
It should say:
as described in Section 4.2.5.1.1. or Section 4.2.5.1.2. --- or --- as described in Section 4.2.5.1 and its subsections.
Notes:
Node IDs may be expressed using either the dtn or ipn URI scheme. The original sentence could be mistakenly read as allowing only the dtn scheme for the source node ID in a Bundle Status Report. The revised wording clarifies that both schemes—dtn (Section 4.2.5.1.1) and ipn (Section 4.2.5.1.2)—are valid, keeping this requirement consistent with the rest of the specification.
Errata ID: 7337
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML
Reported By: Carsten Bormann
Date Reported: 2023-02-06
Verifier Name: Erik Kline
Date Verified: 2025-08-11
Section Appendix B says:
; Actual CBOR data embedded in a byte string, with optional tag to indicate so. ... ; Extension block type, which does not specialize other than the code/number ... payload-block = payload-block-structure .within canonical-block- structure
It should say:
; Actual CBOR data embedded in a byte string, with optional tag to
; indicate so.
...
; Extension block type, which does not specialize other than the
; code/number
...
payload-block = payload-block-structure .within
canonical-block-structure
Notes:
Various line breaking events cause syntax errors while parsing Appendix B.
--- notes ---
Changed from Technical to Editorial as it seems like this was just a tooling/formatting issue.
Status: Reported (1)
RFC 9171, "Bundle Protocol Version 7", January 2022
Note: This RFC has been updated by RFC 9713, RFC 9758
Source of RFC: dtn (int)
Errata ID: 8645
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Felix Flentge
Date Reported: 2025-11-19
Section 4.2.8 says:
4.2.8. Block-Type-Specific Data Block-type-specific data in each block (other than the primary block) SHALL be the applicable CBOR encoding of the content of the block. Details of this representation are included in the specification defining the block type.
It should say:
4.2.8. Block-Type-Specific Data Block-type-specific data in each block (other than the primary block) SHALL be represented as a single definite-length CBOR byte string encoding the block-specific content of the block. Details of this encoding are included in the specification defining the block type and may use CBOR or any other form of encoding.
Notes:
According to 4.3.2 the only applicable CBOR representation for block-type-specific data is a definite-length byte string. The current text has lead to some misunderstandings that any CBOR item could be used as block-type-specific data. This is especially problematic for BPSEC which is assuming a CBOR byte string. The CDDL in Appendix B of RFC 9171 correctly describes block-type-specific-data as CBOR byte string.
Status: Held for Document Update (4)
RFC 9171, "Bundle Protocol Version 7", January 2022
Note: This RFC has been updated by RFC 9713, RFC 9758
Source of RFC: dtn (int)
Errata ID: 7272
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Sipos
Date Reported: 2022-12-12
Held for Document Update by: Erik Kline
Date Held: 2025-08-11
Section 4.2.5.1.1 says:
dtn-hier-part = "//" node-name name-delim demux ; a path-rootless node-name = reg-name demux = *VCHAR
It should say:
dtn-hier-part = "//" node-name name-delim demux [ "?" query ] node-name = reg-name demux = path-rootless / path-empty
Notes:
The demux portion of an EID should match only URI path segments and not match query or fragment URI parts. A fragment part should not actually be sent as encoded EID to be consistent with other URI uses (e.g. HTTP). The administrative endpoint is the allowed empty demux path.
--- see also ---
* https://mailarchive.ietf.org/arch/msg/dtn/7cdgvvfv7Tg3ivLwCW-UFjgvWsc/
Errata ID: 7881
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Huff
Date Reported: 2024-04-03
Held for Document Update by: Erik Kline
Date Held: 2024-04-07
Section 6.1.1 says:
The first element of each bundle status item SHALL be a status indicator, a Boolean value indicating whether or not the corresponding bundle status is asserted, encoded as a CBOR Boolean value.
It should say:
The first element of each bundle status item SHALL be a status indicator, a Boolean value indicating whether or not the corresponding bundle status is asserted, encoded as a CBOR simple value. A value of 'true' SHALL be encoded as a CBOR simple value with additional information 21. A value of 'false' SHALL be encoded as a CBOR simple value with additional information 20.
Notes:
The CBOR spec does not define a 'Boolean' type (RFC8949). It's become common practice to encode boolean values as simple values (major type 7), with additional information 21 indicating 'true' and additional information 20 indicating 'false' (RFC9254, RFC8152). However, this should be explicitly stated for clarity.
--- comments ---
The original text refers to "Boolean values" and not to any "Boolean type"; it is technically correct as is.
As noted, CBOR doesn't have a specific "type" per se for a Boolean, but RFC 8948 S3.3 clearly specifies an encoding for `true` and `false`.
That said, there might be room here for additional clarity for implementers if there is ever to be a 9171bis.
Errata ID: 8376
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ed Birrane
Date Reported: 2025-04-07
Held for Document Update by: Erik Kline
Date Held: 2025-08-11
Section 5.8 says:
If the fragmented bundle is not a fragment or is the fragment with offset zero, then all extension blocks of the fragmented bundle MUST be replicated in the fragment whose offset is zero.
It should say:
All extension blocks of the fragmented bundle MUST be represented in at least one fragment.
Notes:
Requiring that the "first fragment" of a bundle contain every extension block of the fragmented bundle can lead to situations where the "first fragment" bundle is, itself, larger than some reasonable MTU.
More generally, more thought needs to be put into the way in which extension blocks from the fragmented bundle are placed into bundles representing fragments. This is particularly an issue if the bundle holding the fragment will also have extension blocks added to it, as there is no evident way to distinguish between extension blocks in a bundle holding a fragment that were part of the fragmented bundle versus extension blocks in a bundle holding a fragment that are not associated with the fragmented bundle.
--- AD notes ---
RFC 9171 ADU Fragmentation has issues with extension blocks and fragmented bundle size. It requires a thorough and consistent update via a separate document (too large for an erratum).
For more context see:
* https://mailarchive.ietf.org/arch/msg/dtn/2lY2RE_onIXCbO-IAPdylsf819s/
* other discussion ongoing on the mailing list
Errata ID: 8377
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ed Birrane
Date Reported: 2025-04-07
Held for Document Update by: Erik Kline
Date Held: 2025-08-11
Section 5.7 says:
If the received bundle is a fragment, the ADU Reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original ADU, processing of the fragmentary bundle whose payload has been replaced by the reassembled ADU (whether this bundle or a previously received fragment) proceeds from Step 2;
It should say:
If the received bundle is a fragment, the ADU Reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original ADU, then the original primary block of the fragmented bundle whose ADU has been reassembled must replace the primary block of the fragmentary bundle whose payload has been replaced by the reassembled ADU. Processing of this fragmentary bundle proceeds from Step 2;
Notes:
When performing bundle fragmentation, the original bundle is never fully reconstituted because the original bundle primary block is never recreated upon reassembly. This means that any extension blocks that require the original bundle primary block to be intact (such as security blocks) cannot verify the reassembled bundle.
A solution to bundle reassembly that allows for the original bundle to be secured and then verified/decrypted upon reassembly needs to be put in place as the text in 9171 currently cannot support this.
--- AD notes ---
RFC 9171 ADU Fragmentation has issues with extension blocks and fragmented bundle size. It requires a thorough and consistent update via a separate document (too large for an erratum).
For more context see:
* https://mailarchive.ietf.org/arch/msg/dtn/2lY2RE_onIXCbO-IAPdylsf819s/
* other discussion ongoing on the mailing list
Status: Rejected (1)
RFC 9171, "Bundle Protocol Version 7", January 2022
Note: This RFC has been updated by RFC 9713, RFC 9758
Source of RFC: dtn (int)
Errata ID: 8495
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Brian Sipos
Date Reported: 2025-07-02
Rejected by: Erik Kline
Date Rejected: 2025-08-11
Section 5.2 says:
Step 2: Processing proceeds from Step 1 of Section 5.4.
It should say:
Step 2: Processing proceeds from Step 1 of Section 5.3.
Notes:
The original text requires bundles transmitted from local endpoints to pass through the forwarding process even if the destination EID is registered by a local application and is expected to result in delivery. This can result in logical confusion for a BPA, because it might be forwarding-to-self which is specifically disallowed in other sections.
The corrected text proceeds to the disposition process which allows transmitted bundles to be delivered locally, as necessary, just the same as received bundles. This avoids possible forwarding-to-self confusion and allows for efficient local-to-local delivery.
--- see also ---
* https://mailarchive.ietf.org/arch/msg/dtn/2hea7LjMlr0CQ6VIR2qhfXq6UiU/
--VERIFIER NOTES--
See discussion in: https://mailarchive.ietf.org/arch/msg/dtn/2hea7LjMlr0CQ6VIR2qhfXq6UiU/