[Sis-dtn] [EXT] bundle multicast

Mon Oct 19 05:40:59 EDT 2026

Scott,

I (just) uploaded current draft of the agenda to the following link:

 <https://spacecomm.sharepoint.com/:x:/r/sites/SIS/Shared%20Documents/SIS-DTN/CWE%20Private/Meeting%20Materials/2026/Fall%202026/SIS-DTN_WG_Fall_2026_Agenda.xlsx?d=w6fc5eb89b5fe4fb289a9f7d860e534a0&csf=1&web=1&e=phfLZ0> SIS-DTN_WG_Fall_2026_Agenda.xlsx  PDF of same is attached.  Looking forward to seeing you online.  Apologies for the delay.

All, Felix created Teams meetings for the DTN WG sessions – please look for his invitation in your email.

Best regards,

Bob

Robert C. Durst

Chair, CCSDS SIS DTN Working Group

Senior Principal Networking and Communication Engineer

Infrastructure, Networking, and Communications Division

The MITRE Corporation

O: 703-983-7535

C: 703-217-7414

N:  <mailto:durst at mitre.org> durst at mitre.org

From: sburleig.sb at gmail.com <sburleig.sb at gmail.com> 
Sent: Sunday, October 18, 2026 9:18 AM
To: 'Felix Flentge' <Felix.Flentge at esa.int>; Robert C Durst <durst at mitre.org>
Subject: RE: [EXT] bundle multicast

Hi, Felix. Yes, we definitely should discuss more. Is there a meeting on Monday? I thought the DTNWG meetings were scheduled for Tuesday through Thursday? More generally, is the final agenda for the meetings posted in some generally accessible

Hi, Felix.  Yes, we definitely should discuss more.  Is there a meeting on Monday?  I thought the DTNWG meetings were scheduled for Tuesday through Thursday?

More generally, is the final agenda for the meetings posted in some generally accessible place?  Also the MeetMe (or whatever) links?  The CWE SIS:DTNWG:documents:meetings:fall2026 folder seems to be empty.

The rules for Provisional registration of a new URI scheme are pretty flexible.  As I recall from our “ipn” experience many years ago, the means by which the syntax and semantics of a new scheme may be Provisionally registered can be quite informal; I am pretty sure that a reference to the existing imc Internet Draft would suffice for now.  If we wait until the inevitable endless wrangling over allocator, group, and service number semantics has advanced to the point where all three of these brand-new IANA registries (not just registrations in existing registries) have been created, I would worry that the deadline for your near-term requirement will have passed.

I agree that full network-wide scalability of multicast will require a “region” (or whatever we decide to call it) architecture definition, and in fact I am drafting yet another such definition (New! Improved!) starting this week; the need is beginning to be recognized in the BundleBone effort.  But that’s not an impediment to getting the basic mechanism established, as we don’t quite yet have a Solar System Internet in place that will need it.

And I also agree that multicast groups could be very large.  That’s exactly the consideration that motivated the batching procedure in 4.4.  You’re right, eid patterns might enter into this somehow as well, but that’s going to be a matter to discuss when we take up design of the multicast group membership announcement protocol (Appendix A).  The current prototype implementation in ION obviously doesn’t support EID patterns, as they had not been defined when it was developed, but I don’t see this as much of an obstacle.

Scott

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Sunday, October 18, 2026 6:02 AM
To: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hi Scott,

Let’s discuss this in more detail in the meeting on Monday. It seems we would still need a scheme definition in some form. I would also prefer a clear specification including the semantics. We may also need to add something about IANA registries (allocator, group and service numbers ).

For the scaling, sure, it is much better than my forwarding rules. Still, full scalability seems difficult if not combines with some way of some regional approach (routing, group registration, …). I am also wondering whether we may have very large groups (all nodes, all nodes under an allocator, maybe using eid patterns), so that the block could be very large.

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>  <sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: 12 October 2026 19:02
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hi, Felix.  No, seriously, provisional definition of a new URI scheme does not require a pre-existing definition in an RFC.  Please see RFC 7595, Section 4.

There is obviously more overhead in publishing two RFCs instead of one.  Our experience has been that publishing even a single RFC takes years and entails endless wrangling over email.  But as you say, this is a discussion that is perhaps best held on the IETF DTN WG mailing list.

I don’t understand why you think the proposed protocol might not scale up.  Exchange of group membership information is obviously needed, and it’s unclear to me that doing this manually by email and static configuration would be simpler than the mechanism described in Appendix A, which is already implemented in ION and has been working well for several years.  One alternative would be simply not to do multicast at all, which is of course an option.  Automatic propagation of detailed topology information is likewise a minimally expensive basis for constructing efficient multicast consignments, and this too has been working well in ION (in the protocol exercised by cpsd) for several years, but (as noted in 4.3) detailed topology information is not a precondition for IMC forwarding.

On my BIBE note: certainly sending a bundle with an imc-scheme destination endpoint but no IMC block would still be legal; as section 1 of the spec makes clear, conformance to the bundle multicast specification is OPTIONAL.  But consider what would happen if such a bundle were received at a node that does conform to the spec: without an imc extension block the node would have no way of knowing how to forward the bundle, so it would most likely discard it.  Of course, we could additionally require that every conformant node also implement your managed forwarding mechanism as a backup in this case; it increases the complexity of implementation somewhat, but perhaps all implementations will comply anyway.  I proposed BIBE as an alternative, for simplicity: an IMC-non-conformant node would simply encapsulate the multicast block in a bundle destined for an ipn-scheme endpoint at some other node that is configured to handle it in managed fashion.

Scott

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Monday, October 12, 2026 6:49 AM
To: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hi Scott,

Yes, your example is correct, and it does not scale up.

(Actually, I am not so sure how well your proposal scales up; it requires the exchange of group membership information and requires topology information to create the consignments. It is probably more flexible as in the forwarding table implementation this information is more implicit in the table entries.)

I am not sure about the IETF/IANA processes but would assume that for a naming scheme we need to define the URI scheme (and the semantics) in an RFC. I would assume that once this is done, we can register the naming scheme (with referring to RFC 9171 as using protocol). I am not sure if there is a large overhead in creating two RFC instead of one (we need to have the content anyway). In my view, there would be an advantage as I hope the imc naming scheme could progress more quickly (it is awaited for in LunaNet). Anyway, maybe this is a discussion best be held on the IETF mailinglist. We can discuss a CCSDS position at the Fall meetings.

I am a bit puzzled about your suggestion in the last paragraph about using BIBE. Does this imply that under the new RFC using imc as a destination without an IMC block would be not allowed? I also would like to avoid that Node 11 explicitly sends to Node 67 maybe the bundle would arrive at Node 68 (eg, another ground station). Node 11 should not worry about which ground station receives the bundle (though we could use an anycast group to resolve this).

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>  <sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: 09 October 2026 17:50
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hello, Felix.  Perhaps I just need to understand your forwarding tables a bit better.

Suppose we consider distribution of a mission data bundle from one sensor node on the Moon (node 11) to three research centers on Earth, at USC (node 91) and MIT (node 92) and CalTech (node 93).  We agree that we don’t want to send the same data multiple times on the trunk link, so we agree that there is a trunk link, yes?  Let’s say it’s from lunar relay orbiter (node 42) to Earth ground station (node 67).  So the data needs to pass from node 11 to 42, from there to 67, and from there to 91, 92, and 93.  Correct?

So my understanding of your forwarding tables is that:

*	Node 11 would be configured to forward every bundle destined for imc:23.2.5 to node 42 (one copy).
*	Node 42 would be configured to forward every bundle destined for imc:23.2.5 to node 67 (one copy).
*	Node 67 would be configured to forward every bundle destined for imc:23.2.5 to three nodes, 91 and 92 and 93 (three copies).

In essence, node 67 would be statically configured to forward the bundles to those three nodes, in advance, rather than dynamically instructed (via extension block attached at node 11) to do so only upon reception of the bundle.  You are doing manually, by configuration, exactly what the IMC protocol does automatically.  Is that correct?

This clearly can work.  I think we agree that it doesn’t scale up but, as you say, it addresses your immediate problem.

But I don’t think it justifies going to the trouble of creating two standards instead of one.  You can implement the approach discussed above immediately.  There’s no need for an RFC or Blue Book that defines the naming scheme.

All that is needed is IANA registration of the “imc” naming scheme (as noted in section 6 of the IMC draft).  This is a fairly simple process that we went through many years ago with the “ipn” scheme; it’s described in RFC 3986, using the online form at https://www.iana.org/protocols/apply <https://urldefense.us/v2/url?u=https-3A__www.iana.org_protocols_apply&d=DwMFaQ&c=Al8V6E3U0yBSSEuVtdZbGtsvjPA49U3WmtZAsdW0D_Q&r=i1B0O5UdEkmVhk8Z7XQVcg&m=Iw6s5uvODOAi5QvEpUpxPeDecxMumPRsIbP2GXb0MMowq09Sd8gBUszU9-MnlXiT&s=NhGKNKNZ7FH3Eb9lQxmAsxMFI2GCMPKwN78Z2vYdeqk&e=> .  This would initially be a Provisional registration, just as the ipn scheme registration was; we’d apply to make it Permanent after the RFC for IMC was published.  The registration would have to cite an application or protocol that uses the scheme, and for that purpose this IMC draft would be sufficient, a good reason to get it posted right now.  But once the imc naming scheme is registered you can immediately start using it as (I think) you propose.

It’s true that the IMC draft has a lot of normative language describing what a conformant implementation SHALL do, but for your deployment that can all be ignored.  As section 1 firmly asserts, “Conformance to the bundle multicast specification is OPTIONAL for BP nodes.”

Instead, at first you would simply construct your routing tables with the configurations in the bulleted list above.  When and if your nodes need to be integrated into a broader network whose nodes do conform to the IMC specification, I would suggest that you make a small change to the forwarding table at node 11 enabling interoperation with everybody: node 11 would simply be reconfigured to encapsulate every bundle destined for imc:23.2.5 in a BIBE bundle whose destination is ipn:67.xx.  Nothing else changes at all.

Scott

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Friday, October 9, 2026 12:56 AM
To: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hi Scott,

I still don’t see a clear reason why we should not separate naming scheme definition from the definition on the IMC extension block and the related forwarding.

The use cases I have in mind are distribution of alerts to lunar assets and distribution of mission data to multiple nodes on Earth. We would like to use multicast to not send the same data multiple times on the trunk link. This could be solved by configuring the “forwarding tables” (we may use the term forwarding rules a bit differently, for me it is what is configured on a single node, for you it seems more to be the generic rules described in a standard). Eg, for a ground station node, I can configure that bundles for imc:23.2.5 shall be forwarded to 3 different next hops (in our implementation this would be three different CLA).

I fully acknowledge that this is not sufficient for more complex scenario, but it does solve our immediate problem (while more scalable solutions are being developed). Having an additional extension block, much more processing and the need to know all group members when sending a bundle (to create the destination set) is much more complex and I don’t see any chances to get this implemented in missions any time soon.

I could imagine that it could be even possible to carefully mix different approaches and I would certainly like to avoid defining different multicast naming schemes because there are different ways to realise multicast delivery. For me, a naming scheme should define the semantics, not the mechanisms to achieve delivery (of course, one is useless without the other but there may be different ways to achieve delivery). If IETF sticks to the combined approach, would it be possible for CCSDS just to adopt the naming scheme definition?

Regarding the other points:

*	I certainly would like to stick to one encoding and would prefer the three-element form (also, for the ipn EID in the extension block).
*	I have usually a slight preference to delete extension blocks and create new ones by a block processing node instead of updating existing block as it seems to make security processing a bit easier but updating is also fine for me (maybe there needs to be some text about IMC extension blocks being potential security targets).

One point which may require some discussions are the temporal aspects. Nodes may join and leave imc endpoints all the time. Maybe we need some clear statement that the destination set is the known group membership by the source node at the time of sending the bundle.

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>  <sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: 08 October 2026 20:31
To: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hi, Felix.  For me the issue is interoperation.  I understand that simple multicast forwarding rules could be developed that would address the static topologies in the CCSDS Reference Scenarios, and if our concern in the DTNWGs were limited to isolated networks built on those static topologies I wouldn’t have written that I-D.  But suppose more complex scenarios are established in the future.

Suppose that a node that is in a subnetwork built on one of those Reference Scenarios, conforming to those simple multicast forwarding rules, is a relay on the path from a multicast bundle source to some topologically distant members of the bundle’s destination multicast group.  The source will forward a bundle with an IMC extension block listing the nodes to which that Reference Scenario node is requested to forward the bundle.  The Reference Scenario node will receive the bundle, ignore the extension block, forward the bundle to all nodes that it knows about that are members of that multicast group – therefore none of the nodes that are on the far side of that Reference Scenario subnetwork – and discard the bundle.  Multicast will have failed.

The IMC draft makes it clear in 4.3 that conformant nodes don’t need to use anything fancy to decide how to forward a multicast bundle; static routing would be absolutely fine.  The mechanism for identifying the best route to every member of every multicast group could be simply “send it to node 11.419”, a single line of code.  I expect this is a subset of the forwarding configuration you do for IPN EIDs.

A side note: at this point I don’t see any need for any sort of inter-regional forwarding extension block.  But the forwarding of multicast bundles equipped with these IMC extension blocks over inter-regional links would automatically – without specification change – enable multicast to operate over an entire network comprising any number of “regions”.  (I know, we’re not there yet!)

Using the same eid scheme for multiple forwarding procedures would be a little like using IPv4 addressing for both IPv4 forwarding and IPv6 forwarding, or for both IPv4 forwarding and BP forwarding.  It’s fine for an isolated network, but I don’t believe it’s a sound basis for an international open standard.

On your other points:

*	I’m fine with supporting just one CBOR encoding of the imc-scheme EIDs; whatever the WGs agree on.
*	Section 3.3 does explicitly say “allocator number and node number as defined in [RFC9758]”, but certainly the text could hammer on this a little more strongly.  Establishing universal allocator numbers and service numbers that would be used in all EID schemes is fine with me, and when those registries are established the specification should be updated to reference them.
*	The “batching” described in 4.4 is simpler and less bandwidth-intensive than using BIBE segmentation for the same purpose, but of course that would be an alternative.
*	I think the procedure you’re talking about here is the “IMC delegate procedure” rather than the delegation procedure itself (which does no deletion of blocks).  I don’t know how to explain it more clearly, but I will work on that if the mailing list discussion concludes that it is difficult.  But the term “consignment” is precisely correct here: it’s the list of group member nodes that the forwarded bundle is being required to convey to its topological neighbor, not simply a subset of another list.  The connotations of assignment and shipment are intended.

Scott

From: Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> > 
Sent: Wednesday, October 7, 2026 11:21 PM
To: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >
Subject: RE: [EXT] bundle multicast

Hi Scott,

Thanks for sharing. I have not done an in-depth review (as I am busy preparing the custody/compressed reporting RFCs) but I would like to share some thoughts:

First, I think the described algorithm is a good one to implement multicast forwarding. I am not sure, whether the partitioning and delegation would count as ‘routing’ but I believe that’s not the point and my wording below may have been a bit sloppy. 

I still think it make sense to separate the BP endpoint identification scheme from an actual implementation of multicast forwarding. In terms of the current OB draft, this may be called “Forwarding Rules”. I believe there is use in having different options for implementing such forwarding rules but having a common naming scheme for all of them:

1.	knowing the very static topologies in eg the CCSDS Reference Scenarios, it seems very straightforward to me to define forwarding rules based on imc EID without the need for an extension block. (In our implementation this would be the same forwarding configuration we do for IPN EID and would be very straightforward to implement)
2.	for more complex scenarios, your solution makes absolutely sense to me
3.	I could imagine that (inter-regional) routing may be supported in the future by extension blocks; maybe (I am just speculating), such extension blocks could also support multicast.

I think it would be great if all this could be using the same imc scheme. For CCSDS, I would think it is appropriate to start with 1 (as it seems sufficient for the near-term scenarios and I believe it could get implemented), for IETF 2 (and in the future 3) makes perfect sense. Separating out 3.1 (+ adding something on IANA registries, see below would allow to do that). We have tried something similar with https://www.ietf.org/archive/id/draft-cavallini-dtn-iac-00.html <https://urldefense.us/v2/url?u=https-3A__www.ietf.org_archive_id_draft-2Dcavallini-2Ddtn-2Diac-2D00.html&d=DwMFaQ&c=Al8V6E3U0yBSSEuVtdZbGtsvjPA49U3WmtZAsdW0D_Q&r=i1B0O5UdEkmVhk8Z7XQVcg&m=Iw6s5uvODOAi5QvEpUpxPeDecxMumPRsIbP2GXb0MMowq09Sd8gBUszU9-MnlXiT&s=IGxTvL5h4K5U1sNCl_T7XmtED_ckdZO0wEe-43VCrSU&e=>  (which I plan to update when I find the time).

Some more comments:

*	I would propose to only specify the three-element CBOR encoding. In my experience, having alternative encodings (though in principle easy to handle) create a lot of issues in practice.
*	I assume the allocator identifier should be the same as for the IPN naming scheme. This should be made explicit. I would probably also align the service number with IPN service numbers and try to have a common group number registry for imc and iac (some service numbers or group numbers may not make sense in all schemes but then these could simply be not used for a given scheme).
*	I am not sure whether the IMC batching is required or if simply BIBE segmentation could be applied if necessary (bundles growing too large may be a more generic issue).
*	Editorial: I have found the step of delegation a bit difficult to understand. Maybe the step of partitioning the set of nodes in an IMC extension block, deleting this block and adding new IMC blocks for different delegates can be explained more explicitly. I would also maybe change the word ‘consignment’ (which I needed to look up 😉) to ‘partition’ which is really what is done (wikepdia: A partition divides a set into parts so that every element belongs to exactly one subset.)

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>  <sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: 07 October 2026 18:51
To: 'Robert C Durst' <durst at mitre.org <mailto:durst at mitre.org> >; Felix Flentge <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >
Subject: RE: [EXT] bundle multicast

Thanks, guys.  I disagree, but let me see if I can offer a reasoned argument why.

First, to Felix’s point that we have an RFC for IPN which does not talk about routing: let’s remember that RFC 9758 does not introduce the IPN scheme.  RFC 9171 does that.  RFC 9758 just hacks it up a bit to save some transmission bytes for BP-using entities who aren’t first in line to request small node numbers.

But it’s true that RFC 9758 does not talk about routing, and in fact neither does RFC 9171 – at least, not “routing” in the sense I understand it, which is computing a route (through network topology) which can be consulted to direct the forwarding of data from the source to the destination via relay (“router”) nodes.

Routing and forwarding are distinct.  RFC 9171 describes BP forwarding in some detail, with more attention necessarily paid to unicast forwarding because that was the initial requirement.  Routing is a problem left to future documents (see RFC 9171 section 1, third bullet of second bullet list).  We don’t have any RFC that describes BP routing at all, as best I can recall; the closest we’ve got is the SABR Blue Book.

And the attached specification doesn’t address routing either – in fact, it expressly declares (in 4.3) that routing is out of scope.  Applying any number of different routing algorithms is perfectly fine; IMC doesn’t care.  Just as Bob points out, data moving through the network can invoke routing algorithms that are suited to different environments.  There is no proposed multicast routing algorithm.  None at all.

What the attached specification does address is multicast forwarding.  That forwarding is wholly, precisely consistent with everything that RFC 9171 says about forwarding – it simply fills in the details of multicast forwarding (for bundle destinations identified by URIs in the imc scheme, i.e., multiicast destinations) in the same way that RFC 9171 provides the details of unicast forwarding (for bundle destinations identified by URIs in the ipn scheme, i.e., unicast destinations).

Defining a separate “imc” naming scheme without defining how to forward bundles to endpoints identified by URIs formed in that scheme would be, in my view, useless.  It would be like defining IP addressing without defining IP, or like defining UDP multicast addressing without defining UDP multicast.

So yes, by all means, let’s publish this naming scheme independently of any routing mechanisms, but not independently of how it’s used.  If we have any interest at all in enabling multicast through the network, we will need to say what this endpoint naming scheme means in operation.

Scott

From: Robert C Durst <durst at mitre.org <mailto:durst at mitre.org> > 
Sent: Wednesday, October 7, 2026 4:46 AM
To: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> ; 'Felix Flentge' <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >
Subject: RE: [EXT] bundle multicast

Sure, happy to do so.

Per Felix’s point, the separation of name (address) and routing is consistent with the approach taken by the Internet community – different portions of the Internet have different connectivity schemes and different economies that affect use of multicast.  Having a common addressing scheme means that data can move through these different areas (regions?) without translation, but can invoke a routing algorithm that is suited to the environment.  I’d very much like to see a common naming scheme for multicast throughout DTN and would like to see flexibility in the application of a multicast routing algorithm that’s suited to the local environment.  That’s a very long way of saying that I’d like to see the naming scheme published independently of the routing mechanism(s).

Best,
Bob

Hi Scott,

Thanks for asking.

>From an ESA (CCSDS) point of view, I would really like to see a separation of the naming scheme and the algorithm(s) to realise multicast. For me, it would make sense to have this as separate RFC (like we have an RFC for IPN which does not talk about routing). I would also think (hope) that a pure naming scheme RFC could be published quickly (well …) while discussion of an algorithms might take longer. I could also imagine that different algorithms (addressing maybe different use cases would be developed in the future). I would assume that CCSDS may initially only adopt the naming scheme part as this is the scope of the planned OB and it might be sufficient for initial use cases.

Of course, you are absolutely free to proceed as you like (though I would probably also bring up this discussion in IETF). In any case, I would be happy to have a look at the draft (before or after posting) and provide some feedback (constructive, I hope). 

Regards,

Felix

From: sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com>  <sburleig.sb at gmail.com <mailto:sburleig.sb at gmail.com> > 
Sent: Tuesday, October 6, 2026 4:50 PM
To: Robert C Durst <durst at mitre.org <mailto:durst at mitre.org> >; 'Felix Flentge' <Felix.Flentge at esa.int <mailto:Felix.Flentge at esa.int> >
Subject: [EXT] bundle multicast

Hi, Bob and Felix. I have finished the Internet Draft I was working on for bundle multicast and am about ready to post it, but I thought I should check with you guys first: do you want to look it over? Scott ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍

Hi, Bob and Felix.  I have finished the Internet Draft I was working on for bundle multicast and am about ready to post it, but I thought I should check with you guys first: do you want to look it over?

Scott

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> ). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20261019/b94cb912/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SIS-DTN_WG_Fall_2026_Agenda.pdf
Type: application/pdf
Size: 68746 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20261019/b94cb912/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 12293 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20261019/b94cb912/attachment-0001.bin>