Subject: [dtn] on endpoint ID schemas

From: <[email-masked]>
Date: Wed, 23 Mar 2022 18:05:31 -0700

Hi, all.  A couple of thoughts on Rick's presentation at the meeting
yesterday:

The definition of Endpoint ID on page 2 isn't quite right.  Endpoint IDs are
just URIs, i.e., text strings.  It is true that the CBOR representation of
an endpoint ID in a bundle is a tuple, more precisely a CBOR array of two
items, URI scheme code number (a CBOR unsigned integer) and scheme-specific
part (whose CBOR encoding depends on the scheme code number).  But for
talking about naming and addressing I think it's easier just to think about
endpoint IDs as URIs.

The multiplicity of every EID formed in the "ipn" scheme is 1 (section
4.2.5.1.2 of 9171).  The multiplicity of an EID formed in the "dtn" scheme
depends on the scheme-specific part:

*	If "none", then the multiplicity is zero.
*	Otherwise, if the first character following the '/' that terminates
the node name is '~' (tilde), then the multiplicity is undefined: at any
moment, the indicated endpoint may have zero, 1, or more than 1 member.
*	Otherwise the multiplicity is 1.

Nodes are the receivers of bundles, and any node may be a member of (that
is, receive bundles sent to) any number of endpoints.

The scheme-specific part of an EID formed in the "ipn" scheme contains two
numeric values, node number and service number.  In that sense, you could
denote an ipn-scheme EID as { id, {node number, service number}}.

On question 1, first, I wouldn't claim that the "dtn" scheme is for
universal use.  (In fact, I am somewhat skeptical that it is of any utility
at all, but that's an argument for a different thread.)  If the information
resource identified by the URL is known to be on the local Internet -
Earth's Internet if you're on Earth, Mars's Internet if you're on Mars, etc.
- then nothing new is needed at all; cURL already works fine as is.  If not,
then I think the cleanest way to enable cURL over DTN might be to edit the
user-provided URL and then just post it.

For example, embed the original URL in a query string (like
url="https://a.b.c/d") and precede it with a host name and port number that
point at a "delay-tolerant HTTPS" server.  The dthttps server examines the
host name in the original URL and uses BP to forward the message to a peer
dthttps server running on the Internet in which that host resides.  The peer
dthttps server posts to the original URL in the usual way, and any result is
similarly returned over BP and then forwarded to the user.

On question 2, I am puzzled.  The ipn schema is just as capable as the dtn
scheme; it simply identifies nodes by number rather than by name.  As far as
I know it is the only schema that has been in continuous operational use
over the past five years.  I don't understand why using numeric identifiers
for global addressability across all possible DTNs is infeasible; this is
something I would like to discuss.  (As noted above, I'm unclear on what the
Working Group should recommend for the usage of the dtn scheme.)

On question 3, as noted in the presentation, the procedure is simply to add
a new scheme name and associated scheme code number to the "Bundle Protocol
URI Scheme Types" registry, maintained by IANA, as described in section 9.6
of 9171.  I actually would like to take a crack at that this year if
possible, adding the "imc" (IPN Multicast) scheme that we've been
prototyping in ION for several years.

---

From: "Stuart William Card" <[email-masked]>
Date: Thu, 24 Mar 2022 10:13:28 -0400

I'll add my thoughts, which are somewhat orthogonal to these, and reflect
my own work focii and personal prejudices. ;-)

(1) Let's continue to use the word "identifier" and keep it strictly
deconflated from "locator".

(2) Let's support identity (not just location) oriented multicast, both in
the internets that are interconnected by a DTN and in a DTN itself.

(3) Let's document how to map between DTN identifiers and other ID types,
including: High Frequency (HF) radio Automatic Link Establishment (ALE)
"addresses" (unfortunate choice of term); and Drone Remote Identification
Protocol (DRIP) Entity Tags (DETs) / Host Identity Protocol (HIP)
[Heirarchical] Host Identity Tags ([H]HITs).

(4) Let's leverage concepts from (3), including some form of
Cryptographically Generated Addresses (CGAs, like [H]HITs).

(5) Let's try somehow to accommodate Information Centric Networking (ICN)
and/or URNs.

(6) A key issue will be name resolution in multiple name spaces. How a
resource identifier is resolved to a location where that resource can be
accessed (e.g. a message [resource] delivered to a daemon [resource]) may
depend on who wants to know, where, when, etc. Obviously in DTN we cannot
depend upon recourse to non-local DNS servers or the like; yet name spaces
will evolve over time. When V'ger returns, it might remember its old name
Voyager 6, but will have no notion of USS Enterprise, much less IKS Amar.

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

-- 
Stuart W. Card, VP & Chief Scientist
Critical Technologies Inc. (CTI)
<[email-masked]>

---

From: Jorge Amodio <[email-masked]>
Date: Thu, 24 Mar 2022 11:23:09 -0500

Getting goosebumps when I see the word "DNS"

Keep in mind that classic DNS resolution will not work properly in a space
environment, you can't wait for several minutes to get a response, you may
lose communications opportunities.

On the other hand things don't change much, so I guess storing a query for
transmission and caching a response could potentially work ...

Still getting goosebumps :-)

Regards
Jorge

---

From: William Ivancic <[email-masked]>
Date: Thu, 24 Mar 2022 14:05:56 -0400

I think DTN RG started mid 2000s if not sooner (it’s been so long).  There is still no official problem statement or requirements document.  Hence no bounded problem space which results in unbounded problems and no workable solutions.  What has been deployed so far with the space community is a very simple, small, highly predictable network.  Thus, stuff like IPN naming and contact graph routing works fine.  

Two very simple questions and very difficult answers.  What do you want to do and Why?  If you can’t answer these two simple questions, you’ll likely be working on DTN for another 15 plus years.

Finally, for those who have not done so, I highly recommend reading John Day’s “Patterns in Network Architecture”.  Pay particular attention to Naming and Addressing.  I think the best example I’ve seen is that at one time the phone number was a location identifier to a point of attachment. Now it is simply an Identifier, completely independent of location or point of attachment. 

Cheers,

Will  

Keep in mind that classic DNS resolution will not work properly in a space environment, you can't wait for several minutes to get a response, you may lose communications opportunities.

On the other hand things don't change much, so I guess storing a query for transmission and caching a response could potentially work ...

Regards

Jorge

On Thu, Mar 24, 2022 at 9:13 AM Stuart William Card <[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 11:28:26 -0700

FWIW, from my understanding at this point I don't think there's anything in
this list that I would disagree with.

Scott

-----Original Message-----
From: Stuart William Card <[email-masked]> 
Sent: Thursday, March 24, 2022 7:13 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn] on endpoint ID schemas

I'll add my thoughts, which are somewhat orthogonal to these, and reflect my
own work focii and personal prejudices. ;-)

> The definition of Endpoint ID on page 2 isn't quite right.  Endpoint 
> IDs are just URIs, i.e., text strings.  It is true that the CBOR 
> representation of an endpoint ID in a bundle is a tuple, more 
> precisely a CBOR array of two items, URI scheme code number (a CBOR 
> unsigned integer) and scheme-specific part (whose CBOR encoding 
> depends on the scheme code number).  But for talking about naming and 
> addressing I think it's easier just to think about endpoint IDs as 
> URIs.
>
>
>
> 4.2.5.1.2 of 9171).  The multiplicity of an EID formed in the "dtn" 
> scheme depends on the scheme-specific part:
>
> the node name is '~' (tilde), then the multiplicity is undefined: at 
> any moment, the indicated endpoint may have zero, 1, or more than 1
member.
> Nodes are the receivers of bundles, and any node may be a member of 
> (that is, receive bundles sent to) any number of endpoints.
>
>
>
> The scheme-specific part of an EID formed in the "ipn" scheme contains 
> two numeric values, node number and service number.  In that sense, 
> you could denote an ipn-scheme EID as { id, {node number, service
number}}.
> universal use.  (In fact, I am somewhat skeptical that it is of any 
> utility at all, but that's an argument for a different thread.)  If 
> the information resource identified by the URL is known to be on the 
> local Internet - Earth's Internet if you're on Earth, Mars's Internet 
> if you're on Mars, etc.
> - then nothing new is needed at all; cURL already works fine as is.  
> If not, then I think the cleanest way to enable cURL over DTN might be 
> to edit the user-provided URL and then just post it.
>
>
>
> url="https://a.b.c/d") and precede it with a host name and port number 
> that point at a "delay-tolerant HTTPS" server.  The dthttps server 
> examines the host name in the original URL and uses BP to forward the 
> message to a peer dthttps server running on the Internet in which that 
> host resides.  The peer dthttps server posts to the original URL in 
> the usual way, and any result is similarly returned over BP and then 
> forwarded to the user.
>
>
>
> On question 2, I am puzzled.  The ipn schema is just as capable as the 
> dtn scheme; it simply identifies nodes by number rather than by name.  
> As far as I know it is the only schema that has been in continuous 
> operational use over the past five years.  I don't understand why 
> using numeric identifiers for global addressability across all 
> possible DTNs is infeasible; this is something I would like to 
> discuss.  (As noted above, I'm unclear on what the Working Group 
> should recommend for the usage of the dtn scheme.)
>
>
>
> On question 3, as noted in the presentation, the procedure is simply 
> to add a new scheme name and associated scheme code number to the 
> "Bundle Protocol URI Scheme Types" registry, maintained by IANA, as 
> described in section
> 9.6

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 11:31:24 -0700

I would suggest that it makes plenty of sense for there to be a Mars Internet that has its own “local” DNS; I agree that you don’t want to wait multiple minutes for a response to a DNS request.

Scott

From: Jorge Amodio <[email-masked]> 
Sent: Thursday, March 24, 2022 9:23 AM
To: Stuart William Card <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [dtn] on endpoint ID schemas

Regards

Jorge

On Thu, Mar 24, 2022 at 9:13 AM Stuart William Card <[email-masked] <mailto:[email-masked]> > wrote:

> utility
> that
> [email-masked] <mailto:[email-masked]> 

-- 
Stuart W. Card, VP & Chief Scientist
Critical Technologies Inc. (CTI)
<[email-masked] <mailto:[email-masked]> >

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

---

From: [email-masked]
Date: Thu, 24 Mar 2022 15:17:05 -0400 (EDT)

Hi All,

A recent discussion between several of us who sport "distinguished grey" 
led to the creation of the following diagram, meant to illustrate how 
multiple Internets interconnecting via a BP backbone could work, with 
discrete local DNS systems in each Internet.

https://www.solarnetone.org/intersquarednet.png

Scott Johnson,
AS32639/SolarNetOne

On Thu, 24 Mar 2022, [email-masked] wrote:

> 
> I would suggest that it makes plenty of sense for there to be a Mars
> Internet that has its own “local” DNS; I agree that you don’t want to wait
> multiple minutes for a response to a DNS request.
> 
>  
> 
> Scott
> 
>  
> 
>       > The definition of Endpoint ID on page 2 isn't quite right. 
>       Endpoint IDs
>       > are
>       > talking about naming and addressing I think it's easier just
>       to think
>       > about
>       > endpoint IDs as URIs.
>       >
>       >
>       >
>       > at all, but that's an argument for a different thread.)  If
>       the
>       > information
>       > Earth's Internet if you're on Earth, Mars's Internet if you're
>       on Mars,
>       > etc.
>       > - then nothing new is needed at all; cURL already works fine
>       as is.  If
>       > not,
>       > dthttps server running on the Internet in which that host
>       resides.  The
>       > peer
>       > dthttps server posts to the original URL in the usual way, and
>       any result
>       > is
>       > scheme; it simply identifies nodes by number rather than by
>       name.  As far
>       > as
>       > over the past five years.  I don't understand why using
>       numeric
>       > identifiers
>       > something I would like to discuss.  (As noted above, I'm
>       unclear on what
>       > the
>       > On question 3, as noted in the presentation, the procedure is
>       simply to
>       > add
>       > a new scheme name and associated scheme code number to the
>       "Bundle
>       > Protocol
>       > URI Scheme Types" registry, maintained by IANA, as described
>       in section
>       > 9.6

---

From: "Nordgren, Bryce -FS" <[email-masked]>
Date: Thu, 24 Mar 2022 21:09:24 +0000

So, on the question "What do you want to do and why?" My view from the peanut gallery can be summed up as:

1] We want to enable reliable and secure information transport which transparently leverages challenged communication links or even physical transport of data when the always-on connected environment is not available.
2] We don't want to make people or machines responsible for knowing internal details of remote networks (e.g., why inquire after an IP address on Earth if you're never going to visit?)
3] We want to provide useful abstractions which lead to the development of apps providing necessary and desirable services to people using the information transport developed in #1.--Apps which need make no assumptions about client connectivity. ("Client" = the person who needs to interact with the app.)

The peanut gallery rests,
Bryce
________________________________
From: dtn <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, March 24, 2022 1:17 PM
To: [email-masked] <[email-masked]>
Cc: 'Jorge Amodio' <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dtn] on endpoint ID schemas

Hi All,

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.solarnetone.org%2Fintersquarednet.png&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ekVCI2nTX%2B3Kin8dKnhUhSImt3dlA%2F6dkT1D%2F0qU55k%3D&amp;reserved=0

Scott Johnson,
AS32639/SolarNetOne

On Thu, 24 Mar 2022, [email-masked] wrote:

>       > url="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa.b.c%2Fd&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BkHOkSKHmXJNd2HUS5QgSEW%2FUAFxIs%2FMlaefLPvvoqw%3D&amp;reserved=0") and precede it with a host name and
>       port number
>       > that
>       > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=k1aSg318g9Dm9O69xTNMQ7%2F8Wr2yl%2B9HnESo6yFYBkg%3D&amp;reserved=0
>       >
>
>
>       --
>       https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=k1aSg318g9Dm9O69xTNMQ7%2F8Wr2yl%2B9HnESo6yFYBkg%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: William Ivancic <[email-masked]>
Date: Thu, 24 Mar 2022 19:59:57 -0400

Very generic statements.  Unbounded so very hard to make headway.

What is the scale?  10s of nodes, 1000s of nodes, millions of nodes?

How long is the disconnection?   Minutes, Hours, Days, Months, Years?

How large are the bundles?  Kilobytes, Megabytes?

Is your network opportunistic or deterministic or both?

// Will

 

From: dtn <[email-masked]> on behalf of "Nordgren, Bryce -FS" <bryce.l.nordgren=[email-masked]>
Date: Thursday, March 24, 2022 at 5:10 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [dtn] on endpoint ID schemas

Bryce

Hi All,

Scott Johnson,
AS32639/SolarNetOne

---

From: Jorge Amodio <[email-masked]>
Date: Thu, 24 Mar 2022 19:27:38 -0500

> Very generic statements.  Unbounded so very hard to make headway.

Have you read rfc4838 ?

- Initially and  near term probably in the low thousands but scaling
rapidly to tens/hundred of thousands as missions like Artemis, robotic
probes, and others progress.
  But the long term vision (100 years) is to have an
architecture/technology that can scale to a Solar System Internet (SSI)

> How long is the disconnection?   Minutes, Hours, Days, Months, Years?
- All the of the above plus seconds, milliseconds

> How large are the bundles?  Kilobytes, Megabytes?
- from small messages to large files like images

> Is your network opportunistic or deterministic or both?
- both

-J

>
>
>
>
> // Will
>
>
>
>
>
>
>
>
>
>
>
> *From: *dtn <[email-masked]> on behalf of "Nordgren, Bryce -FS"
> <bryce.l.nordgren=[email-masked]>
> *Date: *Thursday, March 24, 2022 at 5:10 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [dtn] on endpoint ID schemas
>
>
>
> 1] We want to enable reliable and secure information transport which
> transparently leverages challenged communication links or even physical
> transport of data when the always-on connected environment is not available.
>
> 2] We don't want to make people or machines responsible for knowing
> internal details of remote networks (e.g., why inquire after an IP address
> on Earth if you're never going to visit?)
>
> 3] We want to provide useful abstractions which lead to the development of
> apps providing necessary and desirable services to people using the
> information transport developed in #1.--Apps which need make no assumptions
> about client connectivity. ("Client" = the person who needs to interact
> with the app.)
>
>
>
> ------------------------------
>
> *From:* dtn <[email-masked]> on behalf of [email-masked] <
> [email-masked]>
> *Sent:* Thursday, March 24, 2022 1:17 PM
> *To:* [email-masked] <[email-masked]>
> *Cc:* 'Jorge Amodio' <[email-masked]>; [email-masked] <[email-masked]>
> *Subject:* Re: [dtn] on endpoint ID schemas
>
>
>
> Hi All,
>
> >       > url="
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa.b.c%2Fd&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BkHOkSKHmXJNd2HUS5QgSEW%2FUAFxIs%2FMlaefLPvvoqw%3D&amp;reserved=0")
> and precede it with a host name and
> >       port number
> >       > that
> 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: Fri, 25 Mar 2022 16:17:53 +0000

Specifications are often defined at multiple levels of abstraction with varying defined scopes, particularly when the task is to describe an ecosystem founded on different principles than the status quo. The abstract layers tend to guide the accretion of the more concrete layers, while the discovery of redundancies, holes or tradeoffs by the development and implementation of concrete layers revises the story told by the abstraction.

For instance, RFC4838 articulates a motivation inspired by several inconvenient consequences of not having access to an always-on connected environment. Since this is the starting point, there's no discussion of leveraging the connected environment if it is available, automatically failing gracefully over to successively less timely modes of delivery. Hence the inclusion of application design principles essentially describes how to optimally leverage the DTN. And yet, in every conceivable scenario where the bundle protocol comes into play, there will be a locally connected environment (a town on Mars or a Planet Called Earth) as well as a remote environment (a different town on Mars, the Moon, or Earth when you're not on it, etc.) Does the app make the decision to use a locally connected environment vs. a challenged link or does the protocol stack? Are the EIDs uniform across the different environments or not? Does my bank have a different URL if I'm locally connected on the Olympus Mons net than it does when I'm vacationing in sunny Valles Marineris?

Likewise, the application design goal of minimizing round trip communications leads immediately to the condition that both ends require knowledge of the information that needs to be transacted, or at least the information that is transacted. That effectively means that the "app" is de-localized. The "client" and the "server" application versions must now be coordinated instead of hosted solely on the webserver. If an update is made to the app, it must somehow be installed on both sides of the challenged link--and not transmitted across the link individually to every client. Even without getting down into the weeds, it's entirely possible to identify additional application design requirements: stable APIs and a robust update mechanism.

And this observation leads to the requirement for some sort of BP version of HTTP+HTML which is optimized for structured data transfer as well as information display. I can imagine that all submissions are prepared offline from cached schema definitions, signed when authentication is required, carry a "schema identifier" which includes a version, and responses to submissions can optionally contain schema definitions for updated version of the app. There actually should be "schema caches" available in each of the locally connected environments, to avoid re-sending the same updates across the challenged links. Schemas may be tabular in nature like a relational database or more flexible like RDF tuples. Infrastructure providers are going to need to provide the means of using the infrastructure efficiently, and adding some infrastructure to support multiple apps developed by unrelated external entities absolutely requires that browsers and caches and apps all work together. None of this requires a lot of time ruminating on the implications of the described system. A very useful question to make explicit (and get agreement on): Is the goal to make an interplanetary internet, or an interplanetary web? This may have much more profound implications than whether we're talking about 1000s to 1000000s of endpoints.

There is always the danger that abstract discussions can twist and turn in the wind, taking pains to avoid imaginary problems while running full speed into real traps--never actually producing anything. On the other hand, prematurely discussing specifics can lead to adding all the flexibility in exactly the wrong places, or even missing the forest for all the trees. The need to iterate up and down the spectrum of abstraction, incorporating lessons learned as one goes, is very real.

>From the peanut gallery,
Bryce
________________________________
From: dtn <[email-masked]> on behalf of Jorge Amodio <[email-masked]>
Sent: Thursday, March 24, 2022 6:27 PM
To: William Ivancic <[email-masked]>
Cc: Nordgren, Bryce -FS <bryce.l.nordgren=[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dtn] on endpoint ID schemas

On Thu, Mar 24, 2022 at 6:59 PM William Ivancic <[email-masked]<mailto:[email-masked]>> wrote:

Have you read rfc4838 ?

- Initially and  near term probably in the low thousands but scaling rapidly to tens/hundred of thousands as missions like Artemis, robotic probes, and others progress.
  But the long term vision (100 years) is to have an architecture/technology that can scale to a Solar System Internet (SSI)

- both

-J

// Will

From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of "Nordgren, Bryce -FS" <bryce.l.nordgren=[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 24, 2022 at 5:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] on endpoint ID schemas

Bryce

From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 24, 2022 1:17 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: 'Jorge Amodio' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] on endpoint ID schemas

Hi All,

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.solarnetone.org%2Fintersquarednet.png&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ekVCI2nTX%2B3Kin8dKnhUhSImt3dlA%2F6dkT1D%2F0qU55k%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.solarnetone.org%2Fintersquarednet.png&data=04%7C01%7C%7Cc5119ceb7c2b4a664a8208da0df666a3%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837649479848972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bQR%2Bmh0ry3QGTjugoMNWRpD1f%2Ft19gDmEl5MwDnIyEg%3D&reserved=0>

Scott Johnson,
AS32639/SolarNetOne

On Thu, 24 Mar 2022, [email-masked]<mailto:[email-masked]> wrote:

> From: Jorge Amodio <[email-masked]<mailto:[email-masked]>>
> To: Stuart William Card <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On Thu, Mar 24, 2022 at 9:13 AM Stuart William Card <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>       > url="https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa.b.c%2Fd&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BkHOkSKHmXJNd2HUS5QgSEW%2FUAFxIs%2FMlaefLPvvoqw%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa.b.c%2Fd&data=04%7C01%7C%7Cc5119ceb7c2b4a664a8208da0df666a3%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837649479848972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FOVv3KxNn678K95G1zPyvxJVrjxc8Hqjk9GpI805raI%3D&reserved=0>") and precede it with a host name and
>       port number
>       > that
>       > [email-masked]<mailto:[email-masked]>
>       > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=k1aSg318g9Dm9O69xTNMQ7%2F8Wr2yl%2B9HnESo6yFYBkg%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&data=04%7C01%7C%7Cc5119ceb7c2b4a664a8208da0df666a3%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837649479848972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6o40PS0UWt6b1G74vQu27dGiHQp%2FLDfBMilvFMB5e5M%3D&reserved=0>
>       >
>
>
>       --
>       <[email-masked]<mailto:[email-masked]>>
>
>
>       [email-masked]<mailto:[email-masked]>
>       https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&amp;data=04%7C01%7C%7Cd3db22d2a3814e149ada08da0dcaf333%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837464326751074%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=k1aSg318g9Dm9O69xTNMQ7%2F8Wr2yl%2B9HnESo6yFYBkg%3D&amp;reserved=0<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn&data=04%7C01%7C%7Cc5119ceb7c2b4a664a8208da0df666a3%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837649479848972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6o40PS0UWt6b1G74vQu27dGiHQp%2FLDfBMilvFMB5e5M%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%7Cc5119ceb7c2b4a664a8208da0df666a3%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837649479848972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6o40PS0UWt6b1G74vQu27dGiHQp%2FLDfBMilvFMB5e5M%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%7Cc5119ceb7c2b4a664a8208da0df666a3%7Ced5b36e701ee4ebc867ee03cfa0d4697%7C0%7C0%7C637837649479848972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6o40PS0UWt6b1G74vQu27dGiHQp%2FLDfBMilvFMB5e5M%3D&reserved=0>