[CESG] (non) agency review of BPv7 BB

Fri May 29 11:31:26 EDT 2026

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 |  <mailto:tomaso.decola at dlr.de> tomaso.decola at dlr.de 
 <http://www.DLR.de/> 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 ( <https://DLR.de/imprint> DLR.de/imprint).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20260529/eee1baaf/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6801 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20260529/eee1baaf/attachment-0001.bin>