[CESG] [EXTERNAL] Re: (non) agency review of BPv7 BB

Fri May 29 16:06:15 EDT 2026

Hi Jim, Clemens,

Thank you for your prompt reply and kind suggestions on how to deal with this situation. 

Although the corrigendum or editorial changes are certainly powerful tools, I’m afraid this could turn problematic for this book. The point 118 about fragmentation is currently supported in RFC 9171 (of which this BPv7 BB is a CCSDS profile), but has been jointly recognized by IETF and CCSDS DTN WGs that this should be instead dropped because of the problems arising with BPSec. As such, it was agreed to already drop this in CCSDS, while in IETF will take a bit longer because of the processes therein implemented. In turn the prototypes have been implemented aligned to this, i.e. without support of fragmentation. If on the contrary we are going to publish this document without this change, we are going to issue a specification supporting the fragmentation, while the companion yellow book and the therein documented prototypes are not. This will be first not acceptable at CESG level in my opinion and in any case providing the community with a document (long awaited by everyone) showing such an important ambiguity. It is well understood that the corrigendum will later fix everything, but in my opinion it is better to have a consistent and complete document already with the very first publication.

Additional thoughts on it also from the other CESG colleagues are more than welcome.

Regards,

Tomaso

From: Lux, Jim (US 430E) <james.p.lux at jpl.nasa.gov> 
Sent: Friday, May 29, 2026 6:01 PM
To: Clemens Heese <Clemens.Heese at esa.int>; de Cola, Tomaso <Tomaso.deCola at dlr.de>; cesg at mailman.ccsds.org
Cc: Felix Flentge <Felix.Flentge at esa.int>; durst at mitre.org
Subject: Re: [EXTERNAL] Re: [CESG] (non) agency review of BPv7 BB

I believe there is some “small” approval process between tech editors fixing stuff and publication.  But I don’t believe it requires a poll or anything like that.

6.2.7.2.3 Corrigenda

Minor technical changes may be made to published normative documents via corrigenda:

a)     The AD shall supply an Area resolution via e-mail to the Secretariat and CESG-exec lists[1] requesting that a corrigendum be issued.

b)    The CCSDS Chief Technical Editor shall

1)    prepare the corrigendum form (see annex D) and document markup and initiate CESG and CMC polls to approve and authorize the corrigendum; and

2)    upon successful completion of the CESG and CMC polls, release the updated document and corrigendum form for publication.

6.2.7.2.4 Editorial Changes to Published Documents

Minor editorial changes may be made to published documents by contacting the CCSDS Chief Technical Editor.

NOTE   –    The procedure for updating a document with editorial changes is part of configuration control procedures in place within the Secretariat.

From: CESG <cesg-bounces at mailman.ccsds.org <mailto:cesg-bounces at mailman.ccsds.org> > on behalf of Clemens Heese via CESG <cesg at mailman.ccsds.org <mailto:cesg at mailman.ccsds.org> >
Reply-To: Clemens Heese <Clemens.Heese at esa.int <mailto:Clemens.Heese at esa.int> >
Date: Friday, May 29, 2026 at 8:38 AM
To: Tomaso de Cola <tomaso.decola at dlr.de <mailto:tomaso.decola at dlr.de> >, "cesg at mailman.ccsds.org <mailto:cesg at mailman.ccsds.org> " <cesg at mailman.ccsds.org <mailto:cesg at mailman.ccsds.org> >
Cc: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >, "durst at mitre.org <mailto:durst at mitre.org> " <durst at mitre.org <mailto:durst at mitre.org> >
Subject: [EXTERNAL] Re: [CESG] (non) agency review of BPv7 BB

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 <mailto:cesg-bounces at mailman.ccsds.org> > on behalf of Tomaso de Cola - SIS AD via CESG <cesg at mailman.ccsds.org <mailto:cesg at mailman.ccsds.org> >
Date: Friday, 29. May 2026 at 17:31
To: cesg at mailman.ccsds.org <mailto:cesg at mailman.ccsds.org>  <cesg at mailman.ccsds.org <mailto:cesg at mailman.ccsds.org> >
Cc: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >; durst at mitre.org <mailto:durst at mitre.org>  <durst at mitre.org <mailto: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 |  <mailto:tomaso.decola at dlr.de> tomaso.decola at dlr.de
 <https://urldefense.us/v3/__http:/www.dlr.de/__;!!PvBDto6Hs4WbVuu7!Pq8E72mLn3_e_qGB24ITZK7JsC448TlFfKt2QK0EtNGNLcCpzhQodL9JZGr60JT4Y01fsibyOYyP8Ysge3iK3fXhaw$> 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://urldefense.us/v3/__https:/dlr.de/imprint__;!!PvBDto6Hs4WbVuu7!Pq8E72mLn3_e_qGB24ITZK7JsC448TlFfKt2QK0EtNGNLcCpzhQodL9JZGr60JT4Y01fsibyOYyP8Ysge3iEy9zN2w$> 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 <mailto:dpo at esa.int> ). 

  _____  

  _____  

[1] An on-line resolutions data base that automatically notifies the Secretariat and CESG when a new Area resolution has been entered has been proposed.  If that capability materializes, the resolution-delivery aspect of the procedure will be updated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20260529/5d84b1dd/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/5d84b1dd/attachment-0001.bin>