[Sis-dtn] IPN 3-tuple naming scheme / 3-element ipn encoding - Pink Sheets

Felix Flentge Felix.Flentge at esa.int
Fri Oct 9 07:12:42 EDT 2026


Hi Brian,

Yes, I would propose to change to:

3.2.3 When encoding an ipn EID, implementations shall use the Three-Element Scheme-Specific Encoding.

One reason to only allow 3-element encoding is exactly that we want to avoid the issues you describe below. It also seems strange to me that we ask for deterministic CBOR encoding in RFC  9171 but are a bit lose about ipn EID encoding and allow alternative forms.

Regards,
Felix

From: Sipos, Brian J. <Brian.Sipos at jhuapl.edu>
Sent: 02 October 2026 17:49
To: Felix Flentge <Felix.Flentge at esa.int>; SIS-DTN WG <sis-dtn at mailman.ccsds.org>
Subject: RE: IPN 3-tuple naming scheme / 3-element ipn encoding - Pink Sheets

Felix,
This generally looks good, one clarification is helpful on requirement 3.2.3. There is a distinction between a node "creating," "originating," or maybe "generating" an EID as it is used here from simply "encoding" an EID created/originated/generated by some other node (and not necessarily referencing that other node).

In order to satisfy RFC 9171 requirements about immutability of primary block and general BPSec needs for Security Source EID to be stable, any forwarding node needs to preserve the exact encoded form of an EID (either two-element or three-element IPN) between its reception and forwarding activity. Meaning whatever EID was received needs to be preserved to whatever is forwarded and for internal processing: transmitting status reports, future compressed reporting, security operations, etc.

Does this make sense? Because this was a pre-existing concern (immutability of EIDs in many circumstances) the text of RFC 9758 was light on this topic and at least one implementation has already run into trouble by not preserving the EID between decode and encode.

Brian S.

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Felix Flentge via SIS-DTN
Sent: Friday, October 2, 2026 11:03 AM
To: SIS-DTN WG <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [EXT] [Sis-dtn] IPN 3-tuple naming scheme / 3-element ipn encoding - Pink Sheets

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> before clicking links or attachments


Dear All,

I have one additional topic for the Fall meetings. As we have discussed before, we should adopt the 3-element IPN scheme with the 3-element encoding asap (it's already in LunaNet).

I have drafted the required changes to the current BPv7 draft:


CCSDS 734.2-P-2_IPN_Naming.docx<https://spacecomm.sharepoint.com/:w:/r/sites/SIS/Shared%20Documents/SIS-DTN/Draft%20Documents/BPv7%20-%20for%20CCSDS/Updated%20IPN%20Naming%20Scheme/CCSDS%20734.2-P-2_IPN_Naming.docx?d=w74c055ba0490424a9ff729e5749c9b2e&csf=1&web=1&e=ZGbHf2> - Full BPv7 with changes tracking. Please add any review comments or proposed changes in this document.

For those who don't have access (yet), I have attached the file.

Although I would not start agency review before we have the BPv7 Blue Book out, I would like to have it ready for Agency Review once the Blue Book is out.

Please review the proposed changes. I would like to get WG consensus on the readiness for Agency Review at the Fall meetings.

Regards,
Felix

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>).
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/sis-dtn/attachments/20261009/4133f4d7/attachment.htm>


More information about the SIS-DTN mailing list