Subject: [dtn] Conventions for DTN EID and node name patterns

From: Brian Sipos <[email-masked]>
Date: Wed, 21 Apr 2021 12:55:45 +0000

All,
Related to the recent chairs call for "Naming and Addressing" topics, I think
there is a need at least within the use of cross-domain validation needed by [1]
for a notion of a "set of Node IDs" or "set of dtn-scheme node names" similar to
how CIDR (and its derivative uses) can be used to specify a block of IP
addresses and also nest a hierarchy of blocks. This concept is a vital component
of route advertising (e.g. in MANET NHDP or BGP) also.

This would also lead into the notion of having an "authorized DTN gateway" which
would be able to perform bundle routing or integrity vouching based on some
authority (a trusted root) authorizing a node to be a trusted gateway for that
set of Node IDs. This would be similar behavior to IP route validation of
RFC6483 [2] and email domain validation of RFC6376 [3]. The gateway contains
some attestation similar to "Behind me sits this set of Nodes; I am willing to
route bundles to them, from them, and I will BIB-sign the outgoing payloads.
Here is the cryptographically-signed thing that validates all of these claims."

Eventually having an on-the-wire protocol for how to advertize these things
would be good (i.e. neighbor or neighborhood discovery), but starting with a
concrete definition of "what does a set of Node IDs look like" would be helpful.
Currently the "dtn" scheme doesn't specify any structure on node names and I
imagine different DTN implementations have different forms of configuration
(probably some kind of expression pattern matching..?). The "ipn" scheme may be
easier if node numbers are allocated in contiguous blocks, which it appears that
they are.
Having an hierarchical structure (and a standard way to express patterns in that
structure) would also greatly simplify delegation of authority the same way the
DNS delegates subdomains or CIDR delegates smaller-block routing.

[1] https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-02.html#section-4
[2] https://www.rfc-editor.org/rfc/rfc6483.html
[3] https://www.rfc-editor.org/rfc/rfc6376.html

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Wed, 21 Apr 2021 16:55:15 +0000

Is "centralization" in terms of naming and certification authorities the way this is going? This seems to imply to me a degree of connectivity often violated by situations in which you'd employ a DTN solution. Even if you used PKI, there's really no way to know whether an otherwise trusted certificate has been revoked by a CA. There's also no way to "look up" a DNS name in a centrally managed but delegated and distributed database in any kind of timely fashion...or even ensure that those lookups are resolved consistently at each node in a DTN...Even in the connected world, I have to wait 24 hours for changes to propagate. How long's that going to take over challenged links that maybe have one scheduled contact a day?

In terms of CAs, it seems to me that either "web of trust" or "zero trust" are better fits philosophically. SSH's strategy of remembering the fingerprint of the remote host, and warning you whenever it changes is also useful and practical.

In terms of IPs, are they necessary in a DTN? Why couldn't your solar-system-ly unique machine readable identity be a key fingerprint or a self-signed certificate?

Again, I'm new and not sure I'm quite picking up everything you're throwing down.

Bryce
________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Wednesday, April 21, 2021 6:55 AM
To: [email-masked] <[email-masked]>
Subject: [dtn] Conventions for DTN EID and node name patterns

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0

This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.

---

From: Rick Taylor <[email-masked]>
Date: Wed, 21 Apr 2021 17:17:28 +0000

Hi Bryce, Brian

As far as I'm concerned, everything is up for discussion.  I can see Brian's point about needing some kind of chain of trust to check keys against, but as Bryce says that does not necessarily require a strict hierarchy.  Also, in the scope of DTN, assuming some immediately accessible trust oracle to check identity is unlikely to be possible.

Key Management as a whole is also a proposed topic for the working group's re-chartering, and how its requirements interact with Naming and Addressing will be very interesting - it particularly highlights the difference between a Name and an Address.  Key Management ought to care if a node is who it says it is (Name), but not really how one gets a bundle there (Address).

Brian, I share your thoughts around gateways between addressing 'regions' - a (regionally) well-known node that has the capability to move bundles between naming areas.  Whether the gateway node is also some kind of trust proxy/authority I think is orthogonal to its role as a name-resolver, even if co-locating the services might be a sensible practical decision.

I look forward to more discussion on these topics, particularly on heterogeneous naming - balancing the desire to name endpoints according to my local scheme, with the desire to reach other endpoints named using a scheme controlled by someone else, without the risk of identity forgery, is a tough challenge.

Cheers,

Rick

From: dtn [mailto:[email-masked]] On Behalf Of Nordgren, Bryce -FS
Sent: 21 April 2021 17:55
To: [email-masked]
Subject: Re: [dtn] Conventions for DTN EID and node name patterns

Bryce

All,

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 21 Apr 2021 17:54:24 +0000

I have similar concerns.  I think it will become important to be able to aggregate BP nodes into named collectives for a variety of purposes, but abandoning the "late binding" concept will not be the right way to do that.

A fundamental principle of DTN is it must accommodate not only nodes' geographical mobility but also their topological mobility.  Over a large network of challenged links, forwarding latencies would fatally inhibit the timely propagation of information about those changes in topology to potential bundle source nodes.

I think trying to base a node aggregation mechanism on the syntax of node IDs would be unnecessarily rigid and in the general case unworkable.  I'd like to develop something more delay-tolerant.

Scott

From: dtn <[email-masked]> On Behalf Of Nordgren, Bryce -FS
Sent: Wednesday, April 21, 2021 9:55 AM
To: [email-masked]
Subject: [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name patterns

Bryce
________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Brian Sipos <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 21, 2021 6:55 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [dtn] Conventions for DTN EID and node name patterns

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4&amp;data=04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&amp;sdata=9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA$>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html&amp;data=04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk$>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html&amp;data=04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA$>

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Wed, 21 Apr 2021 18:36:57 +0000

Nodes (I think here I mean entities having an IP or VIP) requiring robust delivery are currently multi-homed. One pays to be located in a data center because, among other things, the availability of redundant network drops that can carry traffic to and from specific IPs. University border routers make choices about sending traffic over the commodity Internet or Internet2. Pretty sure the DTN is all about robust delivery: having multiple delivery options with rapid ad-hoc failover. Perhaps an axiom is: Robust == multiple delivery options.

"Node aggregation" may not be meaningfully different than the answer to "What node is the next hop for Bundle X from my perspective?" All next hops look like the aggregation of all the nodes which are "behind" that hop. Seems like probing how a Level 2 ethernet switch sends data out the correct port based on MAC addys would be instructive prior art. Or routing protocols between Level 3 routers. Does a node at the start (or in the middle) really care how the other end organizes the last-mile hops? We wouldn't want to re-invent the routing wheel just because the terminology is different.

The ability to rapidly switch from "infrastructure mode" where a mountaintop gateway handles traffic into a city, to "ad hoc mode" where USB sticks start carrying data from surrounding areas; may be desirable. Allowing the two to co-exist may also be desirable.

Bryce

________________________________
From: Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Sent: Wednesday, April 21, 2021 11:54 AM
To: Nordgren, Bryce -FS <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: Conventions for DTN EID and node name patterns

I have similar concerns.  I think it will become important to be able to aggregate BP nodes into named collectives for a variety of purposes, but abandoning the “late binding” concept will not be the right way to do that.

A fundamental principle of DTN is it must accommodate not only nodes’ geographical mobility but also their topological mobility.  Over a large network of challenged links, forwarding latencies would fatally inhibit the timely propagation of information about those changes in topology to potential bundle source nodes.

I think trying to base a node aggregation mechanism on the syntax of node IDs would be unnecessarily rigid and in the general case unworkable.  I’d like to develop something more delay-tolerant.

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4%26data%3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA%24&data=04%7C01%7C%7Cd369603c790047caf06108d904ee8895%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637546244810538104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kWXcd0CRHvfiwkekze%2BxxA3XKiE2s8I6qi3%2Bl9mKbxc%3D&reserved=0>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html%26data%3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk%24&data=04%7C01%7C%7Cd369603c790047caf06108d904ee8895%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637546244810538104%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g4IFV7M6UlkCF1xGDG3HsIMxoZrJcfMGSU12pwui4Bs%3D&reserved=0>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html%26data%3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA%24&data=04%7C01%7C%7Cd369603c790047caf06108d904ee8895%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637546244810548060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bl%2BbWqFDiRDvlNrT1J6s02u2MvoDunH1qi89Ig1AaYQ%3D&reserved=0>

---

From: Brian Sipos <[email-masked]>
Date: Wed, 21 Apr 2021 19:24:20 +0000

Bryce and Scott,
I wasn't clear that what I'm asking about is not a service to resolve or list node names, but a way of structuring node names which can allow logical operations on them. This would perform the same function as CIDR for IP address blocks; instead of enumerating 1024 IP addresses I can concisely state the CIDR block a.b.c.0/22.

If DTN node names were to follow a hierarchical pattern (the way that DNS names do, but not implying anything about the DNS protocol or services) then it would be possible to:

  1.  Concisely configure or advertise routing willingness, either from source or to destination.
  2.  Perform set logic similar to how I can guarantee that a.b.c.0/26 is a subset of a.b.c.0/22 without needing to actually do complex set calculations.
  3.  Provide a basis for some organizational efficiency: as in the Integrity Gateway forwarding node providing DKIM-like security service for other nodes (can you specify which other nodes a-priori? or without enumeration?)

Again, I'm not speaking of any relationship to CLs, resolution to next-hop CL, neighbor nodes, or anything like that. The point of this structured naming would be for efficiency of space (avoiding a need to enumerate node names) and for time (avoiding a need to update tables as topology changes). And just like I don't need to structure an IP network to use nested CIDR blocks, it certainly makes configuring (and troubleshooting) simpler and easier. I'm also not talking about naming authorities (the way DNS allows a hierarchy of authorities as well as a hierarchy of names) just name patterns.

For example, completely-made-up glob patterns of "dtn://org-abc-*/" or "dtn://*-someother/" could be usable for conciseness but there's no guaranteed relationships between those sets, while "dtn://org-abc-def-*/" is certainly a subset of that first pattern. Even having a standardized form of what a glob would look like helps answer my question of how to define or compare them (e.g. are multiple wildcards allowed? needed?).
________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Sent: Wednesday, April 21, 2021 13:54
To: Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dtn] Conventions for DTN EID and node name patterns

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4%26data%3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA%24&data=04%7C01%7CBSipos%40rkf-eng.com%7Cfd6fd12cbd1043ec52cd08d904ee8a4e%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637546244882302893%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s%3D&reserved=0>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html%26data%3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk%24&data=04%7C01%7CBSipos%40rkf-eng.com%7Cfd6fd12cbd1043ec52cd08d904ee8a4e%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637546244882312887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BDzgWo8aKl%2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc%3D&reserved=0>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html%26data%3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA%24&data=04%7C01%7CBSipos%40rkf-eng.com%7Cfd6fd12cbd1043ec52cd08d904ee8a4e%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637546244882322882%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf%2BBG5M8N0%3D&reserved=0>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 21 Apr 2021 19:33:23 +0000

I agree with all this.  In particular, I would suggest that all routing/forwarding in DTN comes down to repeatedly asking this question: given the time-to-live, size, etc. of this bundle destined for node X, and given my expectations of connectivity among nodes on plausible paths from myself to X, should I send a copy of this bundle to node Q which is topologically adjacent to me?

In an opportunistic forwarding environment the answer to this question at any single node may be "Yes" several times, as there may be no single path from that node that offers high enough likelihood of successful delivery to X.

In a deterministic forwarding environment - managed static routes, or contact graph routing - the answer at any single node will be "Yes" at most once.

But I think this commonality underlies the coexistence you're talking about, and the mechanisms for providing the information on which the answer is based are orthogonal to the question itself.

Scott

From: dtn <[email-masked]> On Behalf Of Nordgren, Bryce -FS
Sent: Wednesday, April 21, 2021 11:37 AM
To: [email-masked]
Subject: [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name patterns

Bryce

________________________________
From: Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>>
Sent: Wednesday, April 21, 2021 11:54 AM
To: Nordgren, Bryce -FS <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: Conventions for DTN EID and node name patterns

Scott

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Nordgren, Bryce -FS
Sent: Wednesday, April 21, 2021 9:55 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name patterns

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24&data=04*7C01*7C*7Cd369603c790047caf06108d904ee8895*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546244810538104*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=kWXcd0CRHvfiwkekze*2BxxA3XKiE2s8I6qi3*2Bl9mKbxc*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!cA1eQZAp2lB8tt4GDQGkrsZ6hCP5P8ZTr7xqBaUE1J89ocY-a2I69hW88c0VriZ8HwwS5-7lVK8$>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24&data=04*7C01*7C*7Cd369603c790047caf06108d904ee8895*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546244810538104*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=g4IFV7M6UlkCF1xGDG3HsIMxoZrJcfMGSU12pwui4Bs*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!cA1eQZAp2lB8tt4GDQGkrsZ6hCP5P8ZTr7xqBaUE1J89ocY-a2I69hW88c0VriZ8HwwSUvPeFyo$>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24&data=04*7C01*7C*7Cd369603c790047caf06108d904ee8895*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546244810548060*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=bl*2BbWqFDiRDvlNrT1J6s02u2MvoDunH1qi89Ig1AaYQ*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!cA1eQZAp2lB8tt4GDQGkrsZ6hCP5P8ZTr7xqBaUE1J89ocY-a2I69hW88c0VriZ8HwwSGZ87k2o$>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 21 Apr 2021 19:43:58 +0000

I'm concerned that baking a particular hierarchical character into the ID of a node makes it impossible to change that node's location in the hierarchy without changing its ID.  Even if hierarchy mobility were not an issue, the syntax would only locate the node within one hierarchy; I think it's possible that collections of nodes may need to be aggregated in different hierarchies for different purposes, so an additional aggregation mechanism would be needed in any case.  I'm still doubtful.

Scott

From: dtn <[email-masked]> On Behalf Of Brian Sipos
Sent: Wednesday, April 21, 2021 12:24 PM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>; Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name patterns

Bryce and Scott,

For example, completely-made-up glob patterns of "dtn://org-abc-*/" or "dtn://*-someother/" could be usable for conciseness but there's no guaranteed relationships between those sets, while "dtn://org-abc-def-*/" is certainly a subset of that first pattern. Even having a standardized form of what a glob would look like helps answer my question of how to define or compare them (e.g. are multiple wildcards allowed? needed?).
________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>>
Sent: Wednesday, April 21, 2021 13:54
To: Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]<mailto:bryce.l.nordgren=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] Conventions for DTN EID and node name patterns

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24&data=04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=ztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY$>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24&data=04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA$>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24&data=04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=TMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ$>

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Wed, 21 Apr 2021 20:21:33 +0000

If admins maintain their own registry of nodes and group membership and then compose operations on those groups themselves, does there need to be a naming scheme?

Drawing from the dhcpd.conf man page, what if the sets were defined like:

group {
  name "Xncd19r";
  next-server ncd-booter;

 host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
  host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
  host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
}

MAC addys are perfect illustration. They have a hierarchy, but it's completely meaningless since its based off manufacturer: you will always be grouping some other way. Maybe you can share your group with others, maybe they can make their own. Either way, you can make set operations tractable.

Moving on to "routing", the use of mass storage as a Sneakernet carrier kind of violates the forwarding model/paradigm. It's more of a "bus" model. If you put it on the USB stick, and the stick visits five other nodes, you may not know if your Bundle was handled by the 1st or 5th node...you may not know if it was accepted at all. Is it always desirable to address the bundle to a specific next node, or is it sometimes better to let a node take it if it has reason to believe its deliverable? This question may apply in any point-to-multipoint kind of topology, where there are many listeners and a single transmitter.

To link these two threads together, "bus" mode may be a very apt application of node groupings.

More questions than answers,
Bryce
________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>
Sent: Wednesday, April 21, 2021 1:43 PM
To: Brian Sipos <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>; Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dtn] Conventions for DTN EID and node name patterns

I’m concerned that baking a particular hierarchical character into the ID of a node makes it impossible to change that node’s location in the hierarchy without changing its ID.  Even if hierarchy mobility were not an issue, the syntax would only locate the node within one hierarchy; I think it’s possible that collections of nodes may need to be aggregated in different hierarchies for different purposes, so an additional aggregation mechanism would be needed in any case.  I’m still doubtful.

Scott

Bryce and Scott,

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24%26data%3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3Dztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY%24&data=04%7C01%7C%7Ca9a5f615bcc846a04ded08d904fdd8a2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637546310612143960%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X%2Bkw4rs3ZxMtm8x1Q8TyjnHkE%2FpHoje2iXtJzHK%2BnvA%3D&reserved=0>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24%26data%3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA%24&data=04%7C01%7C%7Ca9a5f615bcc846a04ded08d904fdd8a2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637546310612153916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo6bJZYXhcFVhesS0vO424A1sz5dcANsQVddCyIqJq8%3D&reserved=0>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24%26data%3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3DTMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ%24&data=04%7C01%7C%7Ca9a5f615bcc846a04ded08d904fdd8a2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637546310612153916%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=h0wvhQZQmt%2F7tIQeM7eDHHR1ikOxEHXpBU7hrlqpIzE%3D&reserved=0>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 21 Apr 2021 20:41:40 +0000

Right, one question in the USB stick model is what get stored on the stick.  Kevin Fall proposed that what lives on the stick could be an entire BP node.  Another approach would be to treat USB sticks as a convergence-layer medium.  In the latter case, maybe the topologically adjacent next node is a virtual node and the USB stick acts like a broadcast or anycast packet.  I know USB transmission of bundles has been implemented but don't remember when or how or by whom.

Scott

From: dtn <[email-masked]> On Behalf Of Nordgren, Bryce -FS
Sent: Wednesday, April 21, 2021 1:22 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name patterns

group {

  name "Xncd19r";

  next-server ncd-booter;

}

To: Brian Sipos <[email-masked]<mailto:[email-masked]>>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>>; Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]<mailto:bryce.l.nordgren=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Scott

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Sipos
Sent: Wednesday, April 21, 2021 12:24 PM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:scott.c.burleigh=[email-masked]>>; Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]<mailto:bryce.l.nordgren=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name patterns

Bryce and Scott,

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3Dztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY*24&data=04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612143960*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=X*2Bkw4rs3ZxMtm8x1Q8TyjnHkE*2FpHoje2iXtJzHK*2BnvA*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiUlKioqKioqKioqKioqJSUqJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGn6i4tWg$>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA*24&data=04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612153916*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=xo6bJZYXhcFVhesS0vO424A1sz5dcANsQVddCyIqJq8*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqKiUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGyp30TOs$>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DTMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ*24&data=04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612153916*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=h0wvhQZQmt*2F7tIQeM7eDHHR1ikOxEHXpBU7hrlqpIzE*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGu3CnlXU$>

---

From: Kevin Fall <[email-masked]>
Date: Wed, 21 Apr 2021 13:52:07 -0700

We'd initially thought a USB stick would naturally be a bundle (or a
collection of them).
But then (after more thinking was applied), it seemed as though a USB or
other storage medium was basically an "inactive" node, and that once given
an execution context (e.g., plugged into a system), it would activate and
start discovering neighbors, etc.

If you want to consider a passive medium to be other than a node, it seems
useful to ask what properties of the medium are or aren't equal to what a
dtn node is.

If you want to consider it more of a "link" than it has to have some
special properties (like its endpoints change), but also we tend to think
of links as having a rate limit (bits per unit time) rather than a capacity
limit (bits), so abstracting it seems a bit awkward.

just some things to consider...
regards,
- Kevin

On Wed, Apr 21, 2021 at 1:41 PM Burleigh, Scott C (US 312B)
<scott.c.burleigh=[email-masked]> wrote:

> Right, one question in the USB stick model is what get stored on the
> stick.  Kevin Fall proposed that what lives on the stick could be an entire
> BP node.  Another approach would be to treat USB sticks as a
> convergence-layer medium.  In the latter case, maybe the topologically
> adjacent next node is a virtual node and the USB stick acts like a
> broadcast or anycast packet.  I know USB transmission of bundles has been
> implemented but don’t remember when or how or by whom.
>
>
>
> Scott
>
>
>
> *From:* dtn <[email-masked]> *On Behalf Of * Nordgren, Bryce -FS
> *Sent:* Wednesday, April 21, 2021 1:22 PM
> *To:* [email-masked]
> *Subject:* [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name
> patterns
>
>
>
> If admins maintain their own registry of nodes and group membership and
> then compose operations on those groups themselves, does there need to be a
> naming scheme?
>
>
>
> MAC addys are perfect illustration. They have a hierarchy, but it's
> completely meaningless since its based off manufacturer: you will always be
> grouping some other way. Maybe you can share your group with others, maybe
> they can make their own. Either way, you can make set operations tractable.
>
>
>
> Moving on to "routing", the use of mass storage as a Sneakernet carrier
> kind of violates the forwarding model/paradigm. It's more of a "bus" model.
> If you put it on the USB stick, and the stick visits five other nodes, you
> may not know if your Bundle was handled by the 1st or 5th node...you may
> not know if it was accepted at all. Is it always desirable to address the
> bundle to a specific next node, or is it sometimes better to let a node
> take it if it has reason to believe its deliverable? This question may
> apply in any point-to-multipoint kind of topology, where there are many
> listeners and a single transmitter.
>
>
>
> ------------------------------
>
> *From:* dtn <[email-masked]> on behalf of Burleigh, Scott C (US
> 312B) <scott.c.burleigh=[email-masked]>
> *Sent:* Wednesday, April 21, 2021 1:43 PM
> *To:* Brian Sipos <[email-masked]>; Burleigh, Scott C (US 312B) <
> scott.c.burleigh=[email-masked]>; Nordgren, Bryce -FS <
> bryce.l.nordgren=[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [dtn] Conventions for DTN EID and node name patterns
>
>
>
> I’m concerned that baking a particular hierarchical character into the ID
> of a node makes it impossible to change that node’s location in the
> hierarchy without changing its ID.  Even if hierarchy mobility were not an
> issue, the syntax would only locate the node within one hierarchy; I think
> it’s possible that collections of nodes may need to be aggregated in
> different hierarchies for different purposes, so an additional aggregation
> mechanism would be needed in any case.  I’m still doubtful.
>
>
>
> Scott
>
>
>
> *From:* dtn <[email-masked]> *On Behalf Of *Brian Sipos
> *Sent:* Wednesday, April 21, 2021 12:24 PM
> *To:* Burleigh, Scott C (US 312B) <
> scott.c.burleigh=[email-masked]>; Nordgren, Bryce -FS <
> bryce.l.nordgren=[email-masked]>; [email-masked]
> *Subject:* [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name
> patterns
>
>
>
> Bryce and Scott,
>
> I wasn't clear that what I'm asking about is not a *service* to resolve
> or list node names, but a way of structuring node names which can allow
> logical operations on them. This would perform the same function as CIDR
> for IP address blocks; instead of enumerating 1024 IP addresses I can
> concisely state the CIDR block *a.b.c.0/22*.
>
>
>
> If DTN node names were to follow a hierarchical pattern (the way that DNS
> names do, but not implying anything about the DNS protocol or services)
> then it would be possible to:
>
>    2. Perform set logic similar to how I can guarantee that *a.b.c.0*/26
>    is a subset of a.b.c.0/22 without needing to actually do complex set
>    calculations.
>    3. Provide a basis for some organizational efficiency: as in the
>    Integrity Gateway forwarding node providing DKIM-like security service for
>    other nodes (can you specify *which* other nodes a-priori? or without
>    enumeration?)
>
> Again, I'm not speaking of any relationship to CLs, resolution to next-hop
> CL, neighbor nodes, or anything like that. The point of this structured
> naming would be for efficiency of space (avoiding a need to enumerate node
> names) and for time (avoiding a need to update tables as topology changes).
> And just like I don't *need to* structure an IP network to use nested
> CIDR blocks, it certainly makes configuring (and troubleshooting) simpler
> and easier. I'm also not talking about naming authorities (the way DNS
> allows a hierarchy of authorities as well as a hierarchy of names) just
> name patterns.
>
>
>
> For example, completely-made-up glob patterns of "dtn://org-abc-*/" or
> "dtn://*-someother/" could be usable for conciseness but there's no
> guaranteed relationships between those sets, while "dtn://org-abc-def-*/"
> is certainly a subset of that first pattern. Even having a standardized
> form of what a glob would look like helps answer my question of how to
> define or compare them (e.g. are multiple wildcards allowed? needed?).
> ------------------------------
>
> *From:* dtn <[email-masked]> on behalf of Burleigh, Scott C (US
> 312B) <scott.c.burleigh=[email-masked]>
> *Sent:* Wednesday, April 21, 2021 13:54
> *To:* Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>;
> [email-masked] <[email-masked]>
> *Subject:* Re: [dtn] Conventions for DTN EID and node name patterns
>
>
>
> I have similar concerns.  I think it will become important to be able to
> aggregate BP nodes into named collectives for a variety of purposes, but
> abandoning the “late binding” concept will not be the right way to do that.
>
>
>
> A fundamental principle of DTN is it must accommodate not only nodes’
> geographical mobility but also their topological mobility.  Over a large
> network of challenged links, forwarding latencies would fatally inhibit the
> timely propagation of information about those changes in topology to
> potential bundle source nodes.
>
>
>
> I think trying to base a node aggregation mechanism on the syntax of node
> IDs would be unnecessarily rigid and in the general case unworkable.  I’d
> like to develop something more delay-tolerant.
>
>
>
> Scott
>
>
>
> *From:* dtn <[email-masked]> *On Behalf Of *Nordgren, Bryce -FS
> *Sent:* Wednesday, April 21, 2021 9:55 AM
> *To:* [email-masked]
> *Subject:* [EXTERNAL] Re: [dtn] Conventions for DTN EID and node name
> patterns
>
>
>
> Is "centralization" in terms of naming and certification authorities the
> way this is going? This seems to imply to me a degree of connectivity often
> violated by situations in which you'd employ a DTN solution. Even if you
> used PKI, there's really no way to know whether an otherwise trusted
> certificate has been revoked by a CA. There's also no way to "look up" a
> DNS name in a centrally managed but delegated and distributed database in
> any kind of timely fashion...or even ensure that those lookups are resolved
> consistently at each node in a DTN...Even in the connected world, I have to
> wait 24 hours for changes to propagate. How long's that going to take over
> challenged links that maybe have one scheduled contact a day?
>
>
>
> In terms of CAs, it seems to me that either "web of trust" or "zero trust"
> are better fits philosophically. SSH's strategy of remembering the
> fingerprint of the remote host, and warning you whenever it changes is also
> useful and practical.
>
>
>
> In terms of IPs, are they necessary in a DTN? Why couldn't your
> solar-system-ly unique machine readable identity be a key fingerprint or a
> self-signed certificate?
>
>
>
> ------------------------------
>
> *From:* dtn <[email-masked]> on behalf of Brian Sipos <
> [email-masked]>
> *Sent:* Wednesday, April 21, 2021 6:55 AM
> *To:* [email-masked] <[email-masked]>
> *Subject:* [dtn] Conventions for DTN EID and node name patterns
>
>
>
> All,
> [1]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0
> <https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3Dztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY*24&data=04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612143960*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=X*2Bkw4rs3ZxMtm8x1Q8TyjnHkE*2FpHoje2iXtJzHK*2BnvA*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiUlKioqKioqKioqKioqJSUqJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGn6i4tWg$>
> [2]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0
> <https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA*24&data=04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612153916*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=xo6bJZYXhcFVhesS0vO424A1sz5dcANsQVddCyIqJq8*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqKiUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGyp30TOs$>
> [3]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0
> <https://urldefense.us/v3/__https:/gcc02.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DTMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ*24&data=04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612153916*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=h0wvhQZQmt*2F7tIQeM7eDHHR1ikOxEHXpBU7hrlqpIzE*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGu3CnlXU$>
>
>
>
>
>
> This electronic message contains information generated by the USDA solely
> for the intended recipients. Any unauthorized interception of this message
> or the use or disclosure of the information it contains may violate the law
> and subject the violator to civil or criminal penalties. If you believe you
> have received this message in error, please notify the sender and delete
> the email immediately.
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Thu, 22 Apr 2021 00:22:17 +0000

Hi Kevin, wondering if the USB transport progressed beyond the ideation phase?

Curious as to whether people have good references for prior work on Sneakernet implemented using either:

  *   Smartphones as mobile DTN nodes
  *   XMPP or some other "eventing" pubsub style protocol to coordinate bundle nodes present on a LAN or WiFi.
  *   Mass storage (USB Sticks/Drives) as passive media

I've looked at the "filesystem" convergence layer for DTN2, which seems to be mostly commented out now. Looking for additional/more-recent/complementary/evolutionary ideas; and/or lessons learned.

Was initially hopeful for the 2nd edition (2021) of "Advances in Delay Tolerant Networking<https://doi.org/10.1016/B978-0-08-102793-6.00001-1>", but the emergency communications chapter is a reprint from the 2015 first edition which, from what I can tell, seems to lean heavily on "DistressNet<https://doi.org/10.1016/j.adhoc.2013.06.008>". DistressNet is a 2013 design focused on Urban Search and Rescue, and uses smartphones mostly as end user display devices because of their 2013 resource constraints...in 2021, I have a 512Gb card in my TracPhone.

Many thanks,
Bryce

________________________________
From: Kevin Fall <[email-masked]>
Sent: Wednesday, April 21, 2021 2:52 PM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: Nordgren, Bryce -FS <[email-masked]>; [email-masked] <[email-masked]>
Subject: [External Email]Re: [dtn] Conventions for DTN EID and node name patterns

[External Email]
If this message comes from an unexpected sender or references a vague/unexpected topic;
Use caution before clicking links or opening attachments.
Please send any concerns or suspicious messages to: [email-masked]

We'd initially thought a USB stick would naturally be a bundle (or a collection of them).
But then (after more thinking was applied), it seemed as though a USB or other storage medium was basically an "inactive" node, and that once given an execution context (e.g., plugged into a system), it would activate and start discovering neighbors, etc.

If you want to consider a passive medium to be other than a node, it seems useful to ask what properties of the medium are or aren't equal to what a dtn node is.

If you want to consider it more of a "link" than it has to have some special properties (like its endpoints change), but also we tend to think of links as having a rate limit (bits per unit time) rather than a capacity limit (bits), so abstracting it seems a bit awkward.

On Wed, Apr 21, 2021 at 1:41 PM Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]<mailto:[email-masked]>> wrote:

Right, one question in the USB stick model is what get stored on the stick.  Kevin Fall proposed that what lives on the stick could be an entire BP node.  Another approach would be to treat USB sticks as a convergence-layer medium.  In the latter case, maybe the topologically adjacent next node is a virtual node and the USB stick acts like a broadcast or anycast packet.  I know USB transmission of bundles has been implemented but don’t remember when or how or by whom.

Scott

group {

  name "Xncd19r";

  next-server ncd-booter;

}

Bryce

Scott

Bryce and Scott,

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3Dztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY*24%26data%3D04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612143960*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3DX*2Bkw4rs3ZxMtm8x1Q8TyjnHkE*2FpHoje2iXtJzHK*2BnvA*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiUlKioqKioqKioqKioqJSUqJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGn6i4tWg%24&data=04%7C01%7C%7Cf915a612a47f407691b708d905077af2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546351952936328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=YeKW2wEtEnHTnVh3N35CGFJH%2F%2BEmkqUc%2Fj3%2F2HO%2B%2F18%3D&reserved=0>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA*24%26data%3D04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612153916*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3Dxo6bJZYXhcFVhesS0vO424A1sz5dcANsQVddCyIqJq8*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqKiUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGyp30TOs%24&data=04%7C01%7C%7Cf915a612a47f407691b708d905077af2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546351952936328%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ib8Rtl7uhYkyJoT80q4C4QjRqRBOJla0CD8M%2FiRNmvI%3D&reserved=0>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fgcc02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DTMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ*24%26data%3D04*7C01*7C*7Ca9a5f615bcc846a04ded08d904fdd8a2*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C0*7C637546310612153916*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3Dh0wvhQZQmt*2F7tIQeM7eDHHR1ikOxEHXpBU7hrlqpIzE*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!dvhRelU-aYCVA7u8LwwrqgiUneCvZ3AiUN_Xifb8fMG9n4I0ClRt8xeweexiYFe1dQVGu3CnlXU%24&data=04%7C01%7C%7Cf915a612a47f407691b708d905077af2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546351952946296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=PhXXtSkVAdRjgMQz52iEYNvLeedNGgcepcwvKctAD8g%3D&reserved=0>

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&data=04%7C01%7C%7Cf915a612a47f407691b708d905077af2%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546351952946296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=m6Fmay%2Bd76CQMwgmfUrhzJf4aMGQtAYgFbWbpDEGH1k%3D&reserved=0>

---

From: Brian Sipos <[email-masked]>
Date: Fri, 23 Apr 2021 00:29:20 +0000

Scott,
I appreciate the concerns of multiple node-set categorizations and the desire to not impose node naming restrictions on end-users. I think per-node routing information would be acceptable for MANET-style regional nets, but the notion of a CIDR block is critical to the performance and function of global routing systems like BGP and to a lesser extent OSPF/IS-IS. Global routing just cannot occur on a per-end-address granularity; the database size and synchronization effort just gets too large.

Similar to how disparate IP networks can be conjoined with an IP tunnel / VPN, it would be possible to use BIBE (or equivalent) to separate a "local node name" (inner bundle) from a "global node name" (outer bundle). The form of the local node name is irrelevant for the purposes of global routing, but the form of the global node name would be structured to allow node-name-pattern aggregation and to conform to some kind of routing hierarchy. The end-entity (or gateway node) would then need to be configured to do that aggregation and encapsulation.

I think an important aspect of this is to _not_ fall into the trap of IP NAT where EIDs are rewritten on-path but to use encapsulation to allow tiered routing. The good thing about encapsulation is that this _doesn't_ require an agreed global naming strategy, only an agreed strategy in each routing tier.

My near-term concerns are then about:

  1.  Coming up with some stable terminology about these things. Stealing from MANET/OSPF/BGP/DNS and the DTN Architecture where appropriate.
  2.  Scoping discussion of some of these behaviors so that "local" concerns and "global" concerns are not intertwined.
  3.  Even in a tiered, encapsulated routing system there is still the logical gap in each tier between "a list of Node IDs" and a default route.  Maybe this is acceptable if the breadth of each tier is not too large.
  4.  Distinguishing between an inter-net router and an inter-node router. Maybe an extension block could be defined to give a "network context" to all of the local EIDs in the bundle.
  5.  Security aspects of BP would need to have the context that Node IDs are really identities only within a single tier, and lower (or is it "higher"?) tiers would need to be considered when making authentication/origination determinations.

________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]>
Sent: Wednesday, April 21, 2021 15:43
To: Brian Sipos <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>; Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: Conventions for DTN EID and node name patterns

Scott

Bryce and Scott,

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24%26data%3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3Dztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY%24&data=04%7C01%7CBSipos%40rkf-eng.com%7C29677933b1014c4b96fc08d904fdd052%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637546310444247064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kflSdnm6fXD335A8pj%2Bny88tCWBI6GgNIErpNznqikw%3D&reserved=0>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24%26data%3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3D*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA%24&data=04%7C01%7CBSipos%40rkf-eng.com%7C29677933b1014c4b96fc08d904fdd052%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637546310444247064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E0S6jQDmWhRpo0e3WzgQRmo0rU2zphWXlifiAljc0%2FE%3D&reserved=0>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fnam10.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24%26data%3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000%26sdata%3DTMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ%24&data=04%7C01%7CBSipos%40rkf-eng.com%7C29677933b1014c4b96fc08d904fdd052%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637546310444257067%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4xvwmHeNCiXJUhUI%2FxySiwT1elT0lr1rjG1Si6PJjrs%3D&reserved=0>

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 23 Apr 2021 04:36:48 +0000

Hi, Brian.  I completely agree that CIDR blocks are critical to the performance of global routing in the Internet.  And certainly BIBE could be used to establish an overlay network, on top of the DTN network, within which encapsulating bundles could be routed based on the topological relationships encoded in the names of the nodes in that overlay network, just like the Internet.

My objection to this is that it is not very delay-tolerant.  Routing would depend on accurate mapping between upper-network topologically significant node IDs and lower-network topologically-insignificant DTN node names, and in a network where round-trip times may be on the order of hours or days I think the accuracy of this mapping would degrade rapidly.

Perhaps the tiered routing you refer to could be quite deep, enabling network decomposition (ultimately) down to "regions" within which DTN routing can be successful.  I think that sort of structure is what will turn out to be needed, but I think using node names and bundle encapsulation layers to form that structure would impose excessive overhead and unnecessarily inhibit node mobility.

Instead, I think using contact plans as the basis for region definition and enabling "passageway" nodes (each of which participates in the contact plans for each of two topologically adjacent regions) to form the global region hierarchy - as you say, the tiered routing structure - dynamically is simpler and more resilient.  I unfortunately don't yet have this concept written up in a form that answers some of the obvious questions, but I hope to do that soon.  I think it's a viable way forward.

Scott

From: Brian Sipos <[email-masked]>
Sent: Thursday, April 22, 2021 5:29 PM
To: Burleigh, Scott C (US 312B) <[email-masked]>; Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]>; Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: Conventions for DTN EID and node name patterns

Scott,

From: Burleigh, Scott C (US 312B) <[email-masked]<mailto:[email-masked]>>

Scott

Bryce and Scott,

Scott

Bryce

All,

[1] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-acme-dtnnodeid-02.html%23section-4&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=9Lc0jEgHt%2BfWnp0RfvEy7fH4ui%2BOwLzchfYBRI2u8Gk%3D&amp;reserved=0<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.ietf.org*2Farchive*2Fid*2Fdraft-ietf-acme-dtnnodeid-02.html*23section-4*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3D9Lc0jEgHt*2BfWnp0RfvEy7fH4ui*2BOwLzchfYBRI2u8Gk*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmcGUCGWA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882302893*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3Dztup6qkigZdioPCIneGQ9K5boaGKm3B3WLAasFV941s*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqKiolJSoqKioqKioqKioqJSUqKiolJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et6fnipDY*24&data=04*7C01*7CBSipos*40rkf-eng.com*7C29677933b1014c4b96fc08d904fdd052*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546310444247064*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=kflSdnm6fXD335A8pj*2Bny88tCWBI6GgNIErpNznqikw*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiUlKioqKioqKioqKioqJSUqJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!aTEyHdxnFKwC86CHYoyl_yp6sPvDI0WVnzkiYgpUqbd_1LhIi1nfiqx6_Onqa0Uu9-O3l-91bxE$>
[2] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6483.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=a7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE%3D&amp;reserved=0<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6483.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3Da7pYNDV25PVCQmj6D8RDsW64lDKyyrzYznTvqqAU4UE*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmUjRU0rk*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882312887*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3D*2BDzgWo8aKl*2BE3nkZnztNPbv1uggb0QHs6DFwdW9YUJc*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Et4e9H9zA*24&data=04*7C01*7CBSipos*40rkf-eng.com*7C29677933b1014c4b96fc08d904fdd052*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546310444247064*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=E0S6jQDmWhRpo0e3WzgQRmo0rU2zphWXlifiAljc0*2FE*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!aTEyHdxnFKwC86CHYoyl_yp6sPvDI0WVnzkiYgpUqbd_1LhIi1nfiqx6_Onqa0Uu9-O3-vhg-dU$>
[3] https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6376.html&amp;data=04%7C01%7C%7Ca0fa5dc5d2f24b9d270408d904c4d3c7%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C1%7C637546065682763057%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=ZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU%3D&amp;reserved=0<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fnam10.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fgcc02.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fwww.rfc-editor.org*2Frfc*2Frfc6376.html*26data*3D04*7C01*7C*7Ca0fa5dc5d2f24b9d270408d904c4d3c7*7Ced5b36e701ee4ebc867ee03cfa0d4697*7C0*7C1*7C637546065682763057*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000*26sdata*3DZFeonfhrV03fmEUu9t2fvdLuGnV6ZvhjPpadeXG4klU*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSU!!PvBDto6Hs4WbVuu7!ZB4EVy3lKfAkVfZFkKhiqn2p43ru_Q4H2t09OIiRvbeCgv2-Fh05oDZJUapHBNQXiNJmJy2YizA*24*26data*3D04*7C01*7CBSipos*40rkf-eng.com*7Cfd6fd12cbd1043ec52cd08d904ee8a4e*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546244882322882*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000*26sdata*3DTMFB7XreKjwmOsiiIvk9iIA7D4QQItUrokf*2BBG5M8N0*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSoqKioqJSUqKioqKioqKioqKiUlKiUlJSUlJSUlJSUlJSUlJSUlJQ!!PvBDto6Hs4WbVuu7!ZjR2Fti7cofxSl7lN2N9CBW-D2_vjcxvhhDn4-3lQmm3c1Z_1QBnGf61vcHLVbwpC-Etsv3kKXQ*24&data=04*7C01*7CBSipos*40rkf-eng.com*7C29677933b1014c4b96fc08d904fdd052*7C4ed8b15b911f42bc8524d89148858535*7C1*7C0*7C637546310444257067*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=4xvwmHeNCiXJUhUI*2FxySiwT1elT0lr1rjG1Si6PJjrs*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUqKioqKioqKioqKiolJSoqJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!aTEyHdxnFKwC86CHYoyl_yp6sPvDI0WVnzkiYgpUqbd_1LhIi1nfiqx6_Onqa0Uu9-O3MFoJzBs$>