<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=utf-8"><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;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.m-3551252296432577542msolistparagraph, li.m-3551252296432577542msolistparagraph, div.m-3551252296432577542msolistparagraph
{mso-style-name:m_-3551252296432577542msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
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:12727196;
mso-list-template-ids:1799499420;}
@list l0:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:120654108;
mso-list-template-ids:857241978;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
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:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
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:;
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:;
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:;
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:;
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:;
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:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:240136937;
mso-list-template-ids:-2144859830;}
@list l2:level1
{mso-level-start-at:8;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:296688092;
mso-list-template-ids:1929705052;}
@list l3:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:928198867;
mso-list-template-ids:-1353938536;}
@list l4:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l4:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l4:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5
{mso-list-id:1067220041;
mso-list-template-ids:-2016278318;}
@list l5:level1
{mso-level-start-at:4;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6
{mso-list-id:1391340915;
mso-list-template-ids:-2099614898;}
@list l6:level1
{mso-level-start-at:9;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7
{mso-list-id:1537082546;
mso-list-template-ids:-1496156520;}
@list l7:level1
{mso-level-start-at:7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8
{mso-list-id:1807504863;
mso-list-template-ids:822017464;}
@list l8:level1
{mso-level-start-at:2;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>In my opinion the architectural flow should utilize a standardized communication protocol running within a DTN, that defines the “standard” services and natively works with a set of standard “registries” as well as a method and schema for creating custom services and registries. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Cybersecurity must be an inherent part of the architecture and this “communication protocol” must be able to perform efficiently and securely over BP implementations (e.g., ION). <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>A standardized protocol will support interoperability and should drive the architectural design of standard “registries.” Rather than the existing registry structure driving the architecture of the communication protocol.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>I would kindly suggest that we consider the CoAP-over-bp protocol, which is being designed for autonomous communication among swarms of spacecraft in DTNs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The design covers the standard request/response mechanism (i.e., GET, POST) including pre-defined and custom resources(services), the concept of Resource Directories, Resource Observation, Discovery, Pub/Sub, etc.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>CoAP-over-bp can also abstract the low level implementation details of the standard services on nodes. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>mehmet<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'><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><b><span style='color:black'>From: </span></b><span style='color:black'>SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> on behalf of "Shames, Peter M (312B)" <Peter.M.Shames@jpl.nasa.gov><br><b>Date: </b>Wednesday, August 29, 2018 at 9:28 AM<br><b>To: </b>"Burleigh, Scott C (312B)" <Scott.C.Burleigh@jpl.nasa.gov>, Vint Cerf <vint@google.com>, "Scott, Keith L (9730-Affiliate)" <kscott@mitre.org><br><b>Cc: </b>"sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org>, SANA Group <ssg@mailman.ccsds.org><br><b>Subject: </b>Re: [Sis-dtn] Proposed registry (and registry changes) to address BP operations in CCSDS.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>What emerges for me is that there is a set of concerns, ranging from architectural to tactical. Another way to look at this is to be clear about drivers, use cases, possible deployments in different phases, and overall interoperability and scalability. Registries in some form, whether they are in the SANA, or distributed, or both must be a part of this story. Likewise routing protocols (local and inter-region), standard services at "relay nodes", network management, service and peering agreements, etc.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>The SANA may have a role in this as an authoritative source for certain information, but it is surely not the only source, especially when there are distributed "colonies" of nodes in other locations distant from Earth. And if we have distributed registries we need a way to keep them in synch. We may not be ready to have this broader discussion, but I would suggest that we at least get clear, at an architectural level, how we see this working in the longer term.</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>Cheers, Peter</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> </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-left:.5in'><b><span style='color:black'>From: </span></b><span style='color:black'>Scott Burleigh <Scott.C.Burleigh@jpl.nasa.gov><br><b>Date: </b>Wednesday, August 29, 2018 at 8:55 AM<br><b>To: </b>Vint Cerf <vint@google.com>, Keith Scott <kscott@mitre.org><br><b>Cc: </b>Peter Shames <Peter.M.Shames@jpl.nasa.gov>, "sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org>, "SANA Steering Group (SSG)" <ssg@mailman.ccsds.org><br><b>Subject: </b>RE: [Sis-dtn] Proposed registry (and registry changes) to address BP operations in CCSDS.</span><o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>One way to look at this, maybe, is that DTN multicast and SABR may be sufficient for operating the network, but they depend on contact plans (and, in the long term, inter-region routing). The developers of contact plans (and IRR topology) are going to need some information to base their planning on. Are SANA registries the best way to make that information available as needed?</span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Scott</span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Vint Cerf <vint@google.com> <br><b>Sent:</b> Wednesday, August 29, 2018 6:04 AM<br><b>To:</b> Scott, Keith L (9730-Affiliate) <kscott@mitre.org><br><b>Cc:</b> Shames, Peter M (312B) <Peter.M.Shames@jpl.nasa.gov>; Burleigh, Scott C (312B) <Scott.C.Burleigh@jpl.nasa.gov>; sis-dtn@mailman.ccsds.org; SANA Group <ssg@mailman.ccsds.org><br><b>Subject:</b> Re: [Sis-dtn] Proposed registry (and registry changes) to address BP operations in CCSDS.</span><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'>two short thoughts:<o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>1. it may be very useful to have some "standard" services for DTN. Not all nodes necessarily implement them, but<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>if they do, they all work the same way. Think TELNET, FTP, SMTP, PING, TCP, UDP, in the Internet context. <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>2. One imagines that store and forward nodes in a DTN network would be expected to have standard services<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>needed to participate in the network as relays, including network management services. <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>v<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'>On Wed, Aug 29, 2018 at 8:16 AM, Scott, Keith L. <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>Comments inline below but what I think is the high-order question pulled up to here:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>So maybe the zero order issue is:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>Who’s going to use the information in the DTN_Network_Services elements of the Site and Aperture Registry and <b>for what</b>? E.g.:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l4 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Find out if a particular site supports DTN forwarding or not.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l4 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Find out who to talk to in order to arrange to route through a particular site.</span><span style='color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in;text-indent:-.25in;mso-list:l4 level2 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Courier New"'><span style='mso-list:Ignore'>o<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Will require a discussion of the site’s SABR contact plan, but OK. Note: contact plans are NOT candidates for inclusion in registries.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l4 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Find out the CBHE Node numbers of nodes associated with the site so I can set up my routing to them.</span><span style='color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in;text-indent:-.25in;mso-list:l4 level2 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Courier New"'><span style='mso-list:Ignore'>o<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>I’ll still need all the convergence layer information that Leigh asserts is somewhat transient and not-well-suited to a registry.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l4 level1 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Know whether I can ping a particular spacecraft or ground station (or send AMS messages to it, or send files to it with CFDP).</span><span style='color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in;text-indent:-.25in;mso-list:l4 level2 lfo2'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Courier New"'><span style='mso-list:Ignore'>o<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>I personally think the idea of registering one level higher in the stack, i.e. the message / file formats, is a bridge too far, and while ping is a well-understood thing and a sometimes-useful diagnostic it will probably not be operationally very interesting.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>For each of the above activities that makes sense (not asserting all of them do, or that the list above is complete):</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo4'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Why is it useful for someone to do this (whether in reference to a ground or space node)?[sort of gets into use cases maybe, but in a backwards sort of way]</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo4'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Is it reasonable / feasible for someone to do this (or what are the constraints, like very remote nodes will need to have this info updated periodically rather than pull-on-demand)?</span><span style='color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in;text-indent:-.25in;mso-list:l1 level2 lfo4'><![if !supportLists]><span style='font-size:10.0pt;font-family:"Courier New"'><span style='mso-list:Ignore'>o<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>Or are there other / better ways to accomplish the task, such as subscribing to a multicast stream? Caution: this assumes that multicast streams are used, known, and distributed.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l1 level1 lfo4'><![if !supportLists]><span style='font-size:10.0pt;font-family:Symbol'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;color:#4472C4'>What are the security implications of making this information available (gets at Leigh’s email)?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><b><span style='color:black'>From: </span></b><span style='color:black'>"Shames, Peter M (312B)" <<a href="mailto:Peter.M.Shames@jpl.nasa.gov" target="_blank">Peter.M.Shames@jpl.nasa.gov</a>><br><b>Date: </b>Tuesday, August 28, 2018 at 5:03 PM<br><b>To: </b>Keith Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>, Scott Burleigh <<a href="mailto:scott.c.burleigh@jpl.nasa.gov" target="_blank">scott.c.burleigh@jpl.nasa.gov</a>>, "<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc: </b>SANA Group <<a href="mailto:ssg@mailman.ccsds.org" target="_blank">ssg@mailman.ccsds.org</a>><br><b>Subject: </b>Re: Proposed registry (and registry changes) to address BP operations in CCSDS.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>I think this whole discussion would benefit from having a few Use Cases (or maybe even more than a few). We have the possibilities of completely terrestrial deployments, completely space deployments, and a mixture of the two. We have fixed nodes, and orbiting nodes, and roving / human nodes, and nodes fixed (or orbiting) in some remote location. We have nodes that may be streaming fountains of data and others that are demand only and others that use a client / server model. And we currently have registries here on Earth, but we may well want to have cached registry information at other locations where there is a cluster of user (and server) nodes. Right now we have no way of supporting anything like that, but we should, IMHO, be thinking about it.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>Aside from limited deployment situations where the nodes, and the services they provide, are "baked in" to the implementation, using registries to manage this makes sense to me. The proposal is to use the existing, and planned, SANA registries to provide such a framework, to extend them as needed for DTN's particular requirements, and to think later (but not too much later) about how to expand this registry model out into the Solar System.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>My assumptions are the following, and pardon me if I do not get the DTN terminology exact:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l3 level1 lfo6'><![if !supportLists]><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>DTN services live on host systems</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>DTN services are provided by DTN Nodes and the applications that access them. Those entities are often instantiated on a particular host … system (?) (in particular hardware) but could move between hosts (which would totally screw up my notion of registering CL addresses). I admit that I tend to think as your definition, but Scott often attempts to educate me otherwise.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l8 level1 lfo8'><![if !supportLists]><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>Host systems may be (fixed) service sites, or user sites, or a combo of both</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>I don’t think DTN has a real position on this – see above. I sort of THINK the answer to what I think you’re asking is ‘yes’ but given that I think the binding between a DTN node and a particular piece of hardware is not necessarily fixed, the question might not make much sense.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo10'><![if !supportLists]><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>Sites (which may be S/C, ground stations, mission sites, user sites, or other) are owned and operated by some organization</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>IMHO I think this is a definition of ‘site’ that should be managed by the site definition of the RMP. Same for 4 and 5 below.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l5 level1 lfo12'><![if !supportLists]><span style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>Sites have various identifiers, including location, ownership, and services</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l5 level1 lfo12'><![if !supportLists]><span style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>Each organization that operates a site will have at least one Point of Contact (PoC) for the services it provides</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l5 level1 lfo12'><![if !supportLists]><span style='mso-list:Ignore'>6.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>DTN Bundle Agents (BA) will be hosted at these Sites</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>Again with the caveat of 1 above, DTN nodes will in many cases be instantiated at Sites.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l7 level1 lfo14'><![if !supportLists]><span style='mso-list:Ignore'>7.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>Each BA will have one (or more) associated, unique, Bundle Node Number, tied to the Site</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>Bundle Node Number </span><span style='font-size:11.0pt;font-family:Wingdings;color:#4472C4'>è</span><span style='font-size:11.0pt;color:#4472C4'> CBHE Node Number, ok.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l2 level1 lfo16'><![if !supportLists]><span style='mso-list:Ignore'>8.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>Each BA may offer one (or more) services, identified by CBHE Service Numbers</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>OK.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;text-indent:-.25in;mso-list:l6 level1 lfo18'><![if !supportLists]><span style='mso-list:Ignore'>9.<span style='font:7.0pt "Times New Roman"'> </span></span><![endif]><span style='font-size:11.0pt'>In addition to the AMS and CFDP application data transfer services (message and file) there will need to be application data oriented services that specify, in some way, the contents of these messages and files. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#4472C4'>Yeah, the missions/applications’ problems, not mine </span><span style='font-size:11.0pt;font-family:"Apple Color Emoji";color:#4472C4'>☺</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>All of this stuff could be registered, and most of the necessary registries exist already (items 3, 4, 5, 6) or enough exists that what is needed is to add the "DTN hooks". Items 7 & 8 are DTN specific. Which of these make sense in registries depend on how you see this information evolving. If growth of the SSI is slow and implementation driven you can probably (continue to) get away with local tables. As soon as the DTN grows significantly, has multiple implementations, and many different agencies involved, I argue that you will need some registries, and that those will need to be deployed "around the SSI" and locally cached for efficiency.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>I don’t think a registry for #6 exists yet, or even understand what such a registry would be unless it’s the proposed ‘DTN Network Services’ element of the Site Registry (containing a CBHE Node number; really a list of CBHE node numbers now that I think about it, since a DTN Node might register in multiple endpoints). </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>It may be that some of these services are of the "well known" variety, similar to HTTP, SMTP, DNS, ARP, for others, like how we handle SLE now, you need to have a private agreement about address, port, and access credentials, all arranged by contacting the PoC for that service. For the SLE services there is even the notion of a service agreement and possible a cost.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>For a set of ‘well-known’ CBHE service numbers I’d tend to agree that those should be known, and MAYBE it makes sense to include which services are supported by a given DTN Node.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>I think including costs in such a registry is folly – costs change, exchange rates change.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>If all of the registry info was just in the SANA registries then I agree with Scott, you could burn a lot of time just finding out what services were available and how to access them. Lots of round-trip query / response traffic, just like happens now in the Internet with DNS, ARP, etc. But that is why I think in the future that we will need some way to distribute these registries, cache them "local" to clusters of users, and keep them in synch. That could use some sort of pub/sub or multi-cast approach between registries.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>I hope this helps the dialogue. Does anyone have a good set of Use Cases that we could leverage?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>I don’t think the whole panoply of nodes (fixed, orbiting, roving, streaming, sensor) really plays into the use cases. If we just want to flesh out the ideas and compare strawmen, I’d say a small collection of mission control/mission science center nodes, a couple ground station nodes, and a pair of spacecraft nodes would suffice.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'>I see the registries as being used primarily by people on the ground with access to them, with information relevant to a particular mission being copied to that mission before launch and updated as needed so the mission isn’t trying to query SANA (which I don’t think is the purpose, correct?) FWIW I didn’t interpret Scott’s discussion as being about remote things querying the registries for info.</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt;color:#4472C4'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'>Cheers, Peter</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in'><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><b><span style='color:black'>From: </span></b><span style='color:black'>Keith Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>><br><b>Date: </b>Tuesday, August 28, 2018 at 8:27 AM<br><b>To: </b>Scott Burleigh <<a href="mailto:Scott.C.Burleigh@jpl.nasa.gov" target="_blank">Scott.C.Burleigh@jpl.nasa.gov</a>>, "<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc: </b>Peter Shames <<a href="mailto:Peter.M.Shames@jpl.nasa.gov" target="_blank">Peter.M.Shames@jpl.nasa.gov</a>>, "SANA Steering Group (SSG)" <<a href="mailto:ssg@mailman.ccsds.org" target="_blank">ssg@mailman.ccsds.org</a>><br><b>Subject: </b>Re: Proposed registry (and registry changes) to address BP operations in CCSDS.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>Interesting, I was interpreting ‘services’ as ‘CBHE service numbers’ pretty literally. Your first comment (about CBHE service numbers for data SOURCES) was not how I interpreted SEA’s comments; I perceived they were looking for the CBHE service #s that a node was … willing to receive on? (plus maybe a flag of ‘I’m willing to forward data’?) Sort of like ‘what are the open (IP) ports on this machine’. Maybe such a registry would only contain the ‘well-known’ CBHE services (things like echo (for those unwise enough to try to use it), AMS, CFDP, …) and not application/mission-specific services (which might use ‘private/experimental’ CBHE service # space anyway)? I think my interpretation aligns more with your question below about <b><i>destinations</i></b> of data. I think I’d leave the (application/mission-specific) data services out of the registry altogether (your notion of the available application data sources) and just address them as you suggest below.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:red'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:red'>Peter – can you clarify?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> --keith</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><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='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><b><span style='color:black'>From: </span></b><span style='color:black'>Scott Burleigh <<a href="mailto:Scott.C.Burleigh@jpl.nasa.gov" target="_blank">Scott.C.Burleigh@jpl.nasa.gov</a>><br><b>Date: </b>Tuesday, August 28, 2018 at 11:13 AM<br><b>To: </b>Keith Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>, "<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>><br><b>Cc: </b>"Shames, Peter M (312B)" <<a href="mailto:Peter.M.Shames@jpl.nasa.gov" target="_blank">Peter.M.Shames@jpl.nasa.gov</a>>, SANA Group <<a href="mailto:ssg@mailman.ccsds.org" target="_blank">ssg@mailman.ccsds.org</a>><br><b>Subject: </b>RE: Proposed registry (and registry changes) to address BP operations in CCSDS.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>I think there’s a little bit of a conceptual disconnect here.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>As I understand it, the reason you would want to know what services – that is, what <b><i>sources</i></b> of data – are supported at a given BP node is that you want to obtain some of that data. To do so, you would send a bundle, requesting the desired data, to the endpoint formed by the ID of the node and the ID of the service that is the data source, and the node would send the data back to you.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>But this sort of client/server data flow requires round-trip communication that can take a long time; it is innately non-delay-tolerant. That is the central point we started with in 1998. The sort of registry we are talking about here might be valuable, but I don’t think it has anything to do with DTN.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>The delay-tolerant way to obtain data is simply to receive it when it is generated by the source; to accomplish this, you join the corresponding multicast group to which the source node publishes the new data. (And, in the long run, I think you pick up previously published data after the fact by joining persistent multicast groups that act like information-centric networking stores.)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>Multicast bundles have sources that are identified by node/service, but of course the sources know their own identities; no need for a registry. The destinations of these bundles are “imc” endpoints identified by multicast group number and, as relevant, service number within multicast group. So a registry of multicast groups would be a very helpful element of DTN infrastructure, but I wouldn’t expect a registry of node/service pairs – or even, really, a registry of nodes – to be of much utility.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>What about knowing which <b><i>destinations</i></b> of data are operating at which BP nodes, do we need a registry for that?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>Certainly it is the case that non-multicast messages have sources and destinations that are identified by node/service. But again the source endpoints are known by the sources themselves, and I am doubtful that any application is going to need a registry of the node/service pairs that identify potential destinations of non-multicast bundles. The scalable and responsive way to provide that information, I think, is for the applications to manage it themselves. E.g.:</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:1.5in'>1.<span style='font-size:7.0pt'> </span><span style='font-size:11.0pt;color:#1F497D'>Node A sends a bundle saying “You can get data X from me” to multicast group Q.</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:1.5in'>2.<span style='font-size:7.0pt'> </span><span style='font-size:11.0pt;color:#1F497D'>Node B, a member of multicast group Q, receives that bundle and sends a non-multicast bundle to node A (the source of the original multicast) saying “Great, please send me X, encrypted.”</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:1.5in'>3.<span style='font-size:7.0pt'> </span><span style='font-size:11.0pt;color:#1F497D'>Node A receives that bundle, uses the public key of A to encrypt X, and sends encrypted X in a non-multicast bundle to B (the source of the request bundle).</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:1.5in'>4.<span style='font-size:7.0pt'> </span><span style='font-size:11.0pt;color:#1F497D'>Node B receives that bundle and uses its private key to decrypt X.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>We could have skipped step 1 by providing this information in a SANA registry; node B could have learned that X was at A by querying the registry. But that would require another round-trip data exchange between node B and the registry; I am skeptical that there is an advantage.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>That said, I don’t object to creating the proposed SANA registries in the near term. For the relatively small-scale and stable application structures we are likely to see over the next few years they may serve us well.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'>Scott</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt;color:#1F497D'> </span><o:p></o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><b><span style='font-size:11.0pt'>From:</span></b><span style='font-size:11.0pt'> Scott, Keith L. <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>> <br><b>Sent:</b> Tuesday, August 28, 2018 5:39 AM<br><b>To:</b> <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br><b>Cc:</b> Burleigh, Scott C (312B) <<a href="mailto:Scott.C.Burleigh@jpl.nasa.gov" target="_blank">Scott.C.Burleigh@jpl.nasa.gov</a>>; Shames, Peter M (312B) <<a href="mailto:Peter.M.Shames@jpl.nasa.gov" target="_blank">Peter.M.Shames@jpl.nasa.gov</a>>; SANA Group <<a href="mailto:ssg@mailman.ccsds.org" target="_blank">ssg@mailman.ccsds.org</a>><br><b>Subject:</b> Proposed registry (and registry changes) to address BP operations in CCSDS.</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>Greetings,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>Peter Shames noted that while there are registries for SANA CBHE Node and Service numbers that will allow us to deconflict node EIDs and have a uniform interpretation of the service numbers, there is nothing that says WHICH services are running at WHICH node, OR anything that associates BP Nodes (in our case identified by CBHE Node IDs) and the services they’re running with ‘Sites’ (using the Service and Site Aperture Registry definition) such as ground stations, spacecraft, etc. This kind of information, while not technically required to make BP work, is part of the administration/operation of the network, and would be expected to change infrequently (and so at least feasible to maintain in a registry).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>The desire is for the DTN WG to identify changes / augmentations to the SANA registries to provide the information above. The attached Registry Management Policy deck includes an overview of the Service Site & Aperture structure on slides 21—23.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>I propose the following strawman for discussion:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in'><span style='font-size:11.0pt'>Change the <span style='color:#4472C4'>Network Services</span> under <span style='color:#00B050'>Site Service Info</span> on slide 22 to be a ‘<span style='color:#C55A11'>mayInclude (0..*)</span> – i.e. allow for possibly multiple network services. This would allow sites that have multiple BP routers, which I’ll admit might be unusual but certainly possible.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.5in'><span style='font-size:11.0pt'>Define a <span style='color:#4472C4'>BP_Network_Service </span>element (registry) that is a logical subclass of the <span style='color:#4472C4'>Network_Services</span> listed on slide 22 as:</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:2.0in'><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><b><span style='font-size:11.0pt'>CBHE Node #,</span></b><span style='font-size:11.0pt'> the CBHE Node Number of the BP Node, hyperlinked to the node number allocation range in the CBHE Node Number Registry</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:2.0in'><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><b><span style='font-size:11.0pt'>POC</span></b><span style='font-size:11.0pt'>: a link to the appropriate SANA registry entry for who to talk to about connecting with this node (e.g. routing through it) [Could be a person or an organization?]</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:2.0in'><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><b><span style='font-size:11.0pt'>List of CBHE Service #s</span></b><span style='font-size:11.0pt'>: A list of CBHE service numbers that can be expected to be running on the node (e.g. CFDP) – hyperlinked to their corresponding entries in the CBHE Service # registry.</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:2.0in'><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'> </span><b><span style='font-size:11.0pt'>List of convergence layers and their information</span></b><span style='font-size:11.0pt'>: so for example, if the node is running a TCPCL on IP address <a href="http://10.1.2.3:1234" target="_blank">10.1.2.3:1234</a>, a UDP CL on port address <a href="http://10.1.2.6:5678" target="_blank">10.1.2.6:5678</a>, and an LTP/Encap CL on virtual channel 3, those would be listed.</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:2.5in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span><span style='font-size:11.0pt;color:red'>Maybe listing the VC isn’t appropriate here? That’s more a function of the mission configuration (e.g. each mission could use a different VC even if all share the same aperture and site, I think)</span><o:p></o:p></p><p class=m-3551252296432577542msolistparagraph style='margin-left:2.5in'><span style='font-family:"Courier New"'>o</span><span style='font-size:7.0pt'> </span><span style='font-size:11.0pt;color:red'>I’d vote for the CL info being a free text field with a convention for entries like TCP:1234:4556 rather than trying to generate a whole sub-structure for CL entries – thoughts?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>Somebody should probably also define an <span style='color:#4472C4'>IP_Network_Service</span> element. That may fall to us as well but could pretty much mirror the BP one (but without CL info).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'>Thoughts on this?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> v/r,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> --keith</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><span style='font-size:10.0pt;color:black'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'>Dr. Keith Scott Office: +1.703.983.6547</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'>Chief Engineer, Communications Network Engineering & Analysis Fax: +1.703.983.7142</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'>Advanced Data Transport Capability Area Lead Email: <a href="mailto:kscott@mitre.org" target="_blank"><span style='color:#7F7F7F'>kscott@mitre.org</span></a></span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#474747'> </span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><span style='font-size:10.0pt;color:black'><a href="http://www.mitre.org/" target="_blank"><b>The MITRE Corporation</b></a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'>M/S J500</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'>7515 Colshire Drive</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'>McLean, VA 22102</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in;line-height:14.0pt;text-autospace:none'><b><span style='font-size:10.0pt;color:#7F7F7F'> </span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><b><span style='font-size:10.0pt;color:#7F7F7F'>MITRE self-signs its own certificates. Information about the MITRE PKI Certificate Chain is available from <a href="https://www.mitre.org/tech/mii/pki/" target="_blank"><span style='color:#7F7F7F'>https://www.mitre.org/tech/mii/pki/</span></a></span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:1.0in'><span style='font-size:11.0pt'> </span><o:p></o:p></p></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in'><br>_______________________________________________<br>SIS-DTN mailing list<br><a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><br><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn" target="_blank">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</a><o:p></o:p></p></blockquote></div><p class=MsoNormal style='margin-left:.5in'><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'>-- <o:p></o:p></p><div><div><p class=MsoNormal style='margin-left:.5in'>New postal address:<o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'>Google<o:p></o:p></p><div><p class=MsoNormal style='margin-left:.5in'>1875 Explorer Street, 10th Floor<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Reston, VA 20190<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>_______________________________________________ SIS-DTN mailing list SIS-DTN@mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn <o:p></o:p></span></p></div></body></html>