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

From: William Ivancic <[email-masked]>
Date: Thu, 22 Apr 2021 22:09:25 -0400

For those interested in naming and addressing, if you haven’t done so, I strongly suggest reading Patterns in Network Architecture by John Day.  It is a tough read, but well worth it.  

Will

From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Date: Thursday, April 22, 2021 at 8:30 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]" <[email-masked]>
Subject: Re: [dtn] Conventions for DTN EID and node name patterns

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 

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:

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 

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? 

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,
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://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. 

_______________________________________________ dtn mailing list [email-masked] https://www.ietf.org/mailman/listinfo/dtn

---

From: Marius Feldmann <[email-masked]>
Date: Fri, 23 Apr 2021 13:48:05 +0200

Hi Will, hi all,

as you mentioned John Day's fundamental work: We are currently working
on a funded R&D project (REDMARS) which focuses on transferring concepts
from RINA to the DTN domain. The project just started in March 2021.
You'll find a short overview of the project via [1] (unfortunately in
German, no English version available yet).

The first topic we started to work on is naming and addressing. Our goal
is to create a mapping between RINA and DTN naming/addressing concepts
and to identify gaps, inconsistencies, ... - additionally we are doing
some exercises with selected communication scenarios where we try to
develop a "RINAish DTN approach".

We can present a short sketch of our findings and thoughts during the WG
interim meeting, if this is of interest.

Marius

[1]
https://www.forschung-it-sicherheit-kommunikationssysteme.de/projekte/redmars2

On 23.04.21 04:09, William Ivancic wrote:
>
> For those interested in naming and addressing, if you haven’t done so,
> I strongly suggest reading /Patterns in Network Architecture/ by /John
> Day.  It is a tough read, but well worth it.  /
>
> / /
>
> /Will/
>
>  
>
>  
>
> *From: *dtn <[email-masked]> on behalf of Brian Sipos
> <[email-masked]>
> *Date: *Thursday, April 22, 2021 at 8:30 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]"
> <[email-masked]>
> *Subject: *Re: [dtn] Conventions for DTN EID and node name patterns
>
>  
>
> 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.
>
>  
>
> 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
>
>  
>
> 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:
>
> 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] <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
>
>  
>
> 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] <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
>
>  
>
> 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] <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://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>
>
>
>
>
>
> 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
>
>
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn