[CESG] (non) agency review of BPv7 BB

[Clemens Heese]

Dear Tomaso,

I see two options:


  *
The chief technical editor can make editorial changes without CMC/CESG approval and agency at any time via an editorial change.
  *
You publish the book without the changes and issue a technical corrigendum (does not require Agency review either), if the technical changes you are proposing is minor and does not break interoperability. We are doing this approach with 142 right now.

Regards,

Clemens

From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Tomaso de Cola - SIS AD via CESG <cesg at mailman.ccsds.org>
Date: Friday, 29. May 2026 at 17:31
To: cesg at mailman.ccsds.org <cesg at mailman.ccsds.org>
Cc: Felix Flentge <Felix.Flentge at esa.int>; durst at mitre.org <durst at mitre.org>
Subject: [CESG] (non) agency review of BPv7 BB

Dear all,

As you may recall, at the last CESG in Hamburg I’ve raised the important point that the DTN WG while performing the revision of the red BPv7 book after the agency reviews realized that some additional changes had to be introduced to the book. These new changes are mostly editorial, i.e. not affecting the normative part reviewed within the conducted agency review, or aimed at clarifying some items according to iterations conducted jointly with the DTN WG within IETF. In light of this, the orientation of the WG would be not to perform another agency review. Formally speaking, however, any new changes not result of revision of RIDs should trigger a new agency review instead.
As discussed and agreed in Hamburg, I’m finally able to share the list of items object of this conversation to assess on your side whether or not the agency review should be performed (you see a RID number just because these items are included in the larger RIDs review excel sheet). As stated above, my and overall WG orientation is that these changes are editorial or clarificatory but not alter the essence of the normative content of the book, whereby a new agency review would be unnecessary (and just wasting time). Your advice on this matters is highly appreciated, either via email or in the next few days at the CCSDS meeting so that we can converge quickly to a decision on this.

Reviewer Name
RID #
Paragraph Number
RID Short Title
From
To
Supporting Analysis
Discussion
116
3.2.2, 3.3.4, PICS #9, PICS #15
dtn:none
3.2.2 - Implementations of this specification are not required to deliver or forward bundles whose source, destination, or report-to endpoint identifiers use the dtn URI scheme in RFC 9171 other than dtn:none.

3.3.4 - Implementations of this specification are not required to be able to source bundles with sending EID dtn:none (anonymous bundles).

PICS #9 - Implementations of this specification are not required to be able to source bundles with sending EID dtn:none (anonymous bundles).

PICS #15 - Delete Row
3.2.2 - Implementations of this specification may forward bundles whose source, destination, or report-to endpoint identifier is the ‘null’ identifier.

3.3.4 - Implementations of this specification are not required to be able to source bundles when sending EID is the null identifier (anonymous bundles).

PICS #9 - Item: Null endpoint | Protocol Feature: Support for the null endpoint

PICS #15 - Delete Row
This is more consistent with RFC 9171 4.2.5.1.1
117
PICS #28
BP Managed Information
Delete Row
Annex C was made an informative section with RID 99. This PICS deletion was overlooked.
118
PICS #, 40, 41, 43, ADU Reassembly and add Section 3.8
Fragmentation/On-Path ADU Reassembly
Delete Rows
3.8 Bundle Fragmentation

3.8.1  CCSDS-compliant implementations shall never fragment bundles according to RfC 9171, Section 5.8.

Note: Problems regarding bundle fragmentation and ADU re-assembly as specified by RfC 9171 have been identified. In particular, BPSEC cannot be applied to fragments and fragmentation of bundles with a BPSEC protected primary header can prevent receiving nodes to confirm primary header authenticity even if the ADU is re-assembled.

3.8.2 CCSDS-compliant implementations are not required to implement Application Data Unit Reassembly according to RfC 9171, Section 5.9.

3.8.3 CCSDS-compliant implementations may discard fragmentary bundles at reception.
Fragmentation not supported for CCSDS compliant implementations.
119
PICS #47, 48, 49
Administrative Records, Bundle Status Reports, Generating Administrative Records
PICS #47 - RFC 9171 section 6.1 | M

PICS #48 - RFC 9171 section 6.1  | M

PICS #49 - M
PICS #47 - RFC 9171 section 6.1
(Mandatory if item 49 is true)  | C

PICS #48 - RFC 9171 section 6.1.1
(Mandatory if item 49 is true)

PICS #49 - O
47 - Requirement is conditional on if Generating Administrative Records is true

48 - Requirement is conditional on if Generating Administrative Records is true

49 - Change to optional feature, not required for functionality/implementation specific
120
PICS #18
BPA Endpoint Registration
Delete PICS#18 and section 3.5.2
Add requirement as a note to section 3.2.3. "Deployed DTN nodes shall use unique IPN numbers assigned by organizations…"
Per interop testing results PICS 18 is untestable and an implementation specific requirement.
121
PICS #18, 3.7
BPSec
Delete PICS#18 and update section 3.7 to: Implementations requiring BPSec should refer to the BPSec specification.
Per BPv7 interop testing discussions, BPSec interoperability testing will be covered with the release of the BPSec Blue Book.

Looking forward to your comments,

Best Regards,

Tomaso
————————————————————————
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D. | Integrated Satellite Systems (INS) Team Leader
Telephone +49 8153 28-2156 | Mobile +49 1727134781 |Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de<mailto:tomaso.decola at dlr.de>
DLR.de<http://www.dlr.de/>

DLR is represented by the Executive Board and employees authorised by it.
Head of DLR's legal department, Linder Hoehe, 51147 Cologne, can provide information (DLR.de/imprint<https://dlr.de/imprint>).


This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20260529/ca236932/attachment-0001.htm>