<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:405688833;
mso-list-type:hybrid;
mso-list-template-ids:1498319002 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1981155533;
mso-list-template-ids:-1526926230;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">FYI. This was from the second half of the IETF DTN WG meeting.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> --keith<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">dtn <dtn-bounces@ietf.org> on behalf of Dr. Keith L Scott <kscott@mitre.org><br>
<b>Date: </b>Thursday, July 28, 2022 at 10:33 AM<br>
<b>To: </b>sburleig.sb@gmail.com <sburleig.sb@gmail.com>, dtn@ietf.org <dtn@ietf.org><br>
<b>Subject: </b>Re: [dtn] [EXT] yet another modest proposal<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">So I can sort of remember SOME IPv4 addresses (at least for a while…) but IPv6? -- forget it. So sure, why not just use (IPN Node) numbers? Bonus if we build a DNS-like service (and some elements of CCSDS
are interested in a whois-like service as well).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">To your point about the IPN DNS-like service being delay-tolerant. Well, in general, yes, such a service should operate over BP and could operate over disruptions/delays. The issue is what happens when this
database changes. Fundamentally, the information has to be synchronized throughout the network. That could be a long/painful process in a DTN, but I’m not sure there’s an alternative.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I’m not sure I agree on the need for something that’s highly processor-efficient; I’d lean more towards something that is highly compressible so that those synchronization efforts are more efficient.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">As I said above, some elements of CCSDS are interested in a ‘whois-like’ service that would map a node number to a point of contact. I think that gets at your notion of the meaninglessness of node numbers
and the ‘hints’ about who ‘owns’ what based on IANA / SANA registry entries. That service would have all the same issues of the DNS-like service, I think.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Again, in the near future, the DNS and whos databases will be reasonably small, and most resolutions are going to be done by people on Earth. For the slightly-longer term we may have folks on the Moon, and
later on Mars which starts to get to be an issue. Good and efficient algorithms for doing the ‘zone transfers’ to support the DNS and whois services would be good, but probably supportable for the next, say, 50-100 years.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">So, I think I agree, numbers are as good as anything and probably better than trying to do string-to-string mappings.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">(My apologies if the above is duplicative; I couldn’t make the second hour of the meeting – it was recorded, right? I’ll try to catch that).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> --keith</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">dtn <dtn-bounces@ietf.org> on behalf of sburleig.sb@gmail.com <sburleig.sb@gmail.com><br>
<b>Date: </b>Wednesday, July 27, 2022 at 9:51 PM<br>
<b>To: </b>dtn@ietf.org <dtn@ietf.org><br>
<b>Subject: </b>[EXT] [dtn] yet another modest proposal</span><o:p></o:p></p>
</div>
<p class="MsoPlainText"><span style="font-size:11.0pt">Hi, all. This is the email on node identifiers that Rick somewhat recklessly invited at the end of our meeting yesterday. It is long. You might want to read it sitting down.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">The bottom line: I propose that all BP nodes be uniquely identified by node numbers -- natural numbers -- full stop.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">The obvious objections to this are:</span><o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoPlainText" style="color:black;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt">Lengthy node numbers are impossible for people to remember, type correctly, or derive semantic sense from. All absolutely true. There should never be any reason
for any human (other than maybe a troubleshooting network engineer or a BP developer) to see or use a node number. Unique node numbers should only be written, processed, or read by computing devices, which will find them extremely convenient. Humans should
only refer to nodes by human-readable, semantically rich character strings. Further notes on this below.</span><o:p></o:p></li><li class="MsoPlainText" style="color:black;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt">Node numbers convey no information about the node. Not entirely correct (as discussed below) but again absolutely true in general. There is no need for node
identifiers to convey information about nodes; that information belongs somewhere else, as discussed below.</span><o:p></o:p></li></ul>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Inconvenience of reference by humans:</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Humans interact with DTN by means of applications, instantiated by computing devices. Those applications can readily utilize a directory service to map between arbitrarily expressive human-readable
names and numbers. DNS is an existence proof.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">The key difference between DNS and the sort of BP directory service I’m suggesting is that the former is not delay-tolerant, while the latter pretty much is. DNS maps between character strings
and IP addresses, which are the names (written in an alphabet of just 0 and 1) of the locations of IP nodes; a BP directory service would map between character strings and node numbers, which are the names (again in binary alphabet) of the nodes themselves.
That means that whenever the address of an IP node changes, the directory (the DNS system) needs to be updated in order for routing to that node to succeed; those updates happen quickly in the Internet but would be unsustainable in a Solar System Internet.
In contrast, changing the location of a BP node would have no effect on a BP directory at all; the same name still refers to the same node.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Naturally, changing the human-readable name of a BP node would affect the operation of BP applications, just as changing the domain name of an IP node affects the operation of Internet applications.
Nothing new there. Actually, there’s no reason there couldn’t be multiple character strings that map to the same BP node number, either to cushion a node’s transition to a new human-readable name or to support abbreviations or nicknames or aliases.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Moreover, there might easily be multiple BP directories managed by different entities, all of which might or might not support the same naming syntax. Nor would all (or, really, any) directories
need to support node number mapping for all nodes in the network – if you’re running a selenium mine on Mars, maybe the directory you consult doesn’t have to include all BP nodes in Malaysia; sort of like phone books. I would propose that we let the community
sort out which syntax(es) they prefer and which directories they prefer; there’s no reason we need to nail this all down now, let’s leave the door open for some creativity in expression. DNS and the World-Wide Web were not envisioned in detail by the original
inventors of TCP/IP, they came along later. Maybe we shouldn’t get ahead of ourselves.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">The key thing is to have a dead-simple, highly processor-efficient and bandwidth-efficient foundation for everybody to build on. That’s what we get by numbering nodes.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Meaninglessness of node numbers:</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">If there are BP directories that map between node numbers and human-readable names, then (a) those human-readable names can themselves be arbitrarily expressive and (b) those human-readable
names (or the numbers themselves) can be used to retrieve as much information about nodes as one could ask for.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">It’s true that all of this mapping and lookup activity is not even remotely delay-tolerant *<b>if</b>* the directories are centrally located and must be queried across 40-minute round-trip times.
But there is zero reason to adopt that model: because the association between a human-readable node name and a node number (and thus the node itself) never changes when the node’s location changes, it’s entirely delay-tolerant to replicate directory contents
across any number of repositories that are IP-local to nodes throughout the network. Again, changes in nodes’ human-readable names themselves – likely rare – would need to be synchronized across all directory replicants, but any alternate node identification
system would have to do the same and would have a much greater impact, as the changes would have to be propagated to all nodes rather than only to all copies of the directory.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">And in fact node numbers need not be entirely devoid of information. We already have a node number assignment mechanism in place in IANA, and part of that mechanism is the delegation of a large
range of node numbers to the CCSDS SANA; SANA, in turn, has already delegated sub-ranges of that range to several NASA centers. Node numbers are a little like Ethernet addresses in this sense. It would not be especially difficult to build lookup software
that would use knowledge of these range delegations (maybe “allotments”, like the gardening space allotments in some European cities) to map immediately from a node number to the entity that assigned that number to that node – maybe termed the “operator” for
the smallest range that includes that node number. Given an operator ID maybe you could look up routing constraints, security rules, whatever. If allotment boundaries are chosen with some care you could use bitmaps for lookup.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Speaking of “allotments”, I will further suggest that there might be a number of other different types of node aggregation that we might want to contemplate in the long term. The notion of
“region” that I’ve been working with in ION is the set of all nodes that are cited as senders and/or receivers of bundles in the contacts that make up a single contact plan; as such, a region bounds the operation of forwarding based on Contact Graph Routing.
It’s tempting to overload “regions” with additional administrative significance, like node (rather than contact plan) management authority or security profile or tariff zone, whatever. We can do that, but I think it’s kind of Procrustean; in the long run
I think we will have greater operational flexibility and efficiency by letting any given node be a member of allotment X, region Q, security domain G, etc., all of which may or may not partially overlap. We don’t know all the requirements yet; let’s not try
to design everything now.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Thanks for reading this far. Let me know what you think.</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black">Scott</span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoPlainText"><span style="font-size:11.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</body>
</html>