<html xmlns:v="urn:schemas-microsoft-com:vml" 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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
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;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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:425077285;
mso-list-type:hybrid;
mso-list-template-ids:-69420766 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
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:;
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:;
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:;
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:;
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:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1132401227;
mso-list-type:hybrid;
mso-list-template-ids:-546659536 67698703 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1: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 l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1: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 l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1: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 l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1445150447;
mso-list-type:hybrid;
mso-list-template-ids:482661994 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2: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 l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2: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 l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2: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 l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I think there’s a little bit of a conceptual disconnect here.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo4"><![if !supportLists]><span style="font-size:11.0pt;color:#1F497D"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo4"><![if !supportLists]><span style="font-size:11.0pt;color:#1F497D"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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.”<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo4"><![if !supportLists]><span style="font-size:11.0pt;color:#1F497D"><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l1 level1 lfo4"><![if !supportLists]><span style="font-size:11.0pt;color:#1F497D"><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:11.0pt;color:#1F497D">Node B receives that bundle and uses its private key to decrypt X.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Scott<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt">From:</span></b><span style="font-size:11.0pt"> Scott, Keith L. <kscott@mitre.org>
<br>
<b>Sent:</b> Tuesday, August 28, 2018 5:39 AM<br>
<b>To:</b> sis-dtn@mailman.ccsds.org<br>
<b>Cc:</b> Burleigh, Scott C (312B) <Scott.C.Burleigh@jpl.nasa.gov>; Shames, Peter M (312B) <Peter.M.Shames@jpl.nasa.gov>; SANA Group <ssg@mailman.ccsds.org><br>
<b>Subject:</b> Proposed registry (and registry changes) to address BP operations in CCSDS.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Greetings,<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">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).<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">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.<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">I propose the following strawman for discussion:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.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:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l2 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l2 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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?]<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l2 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l2 level1 lfo2">
<![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><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 10.1.2.3:1234, a UDP CL on port address
10.1.2.6:5678, and an LTP/Encap CL on virtual channel 3, those would be listed.<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l2 level2 lfo2">
<![if !supportLists]><span style="font-size:11.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: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><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.5in;text-indent:-.25in;mso-list:l2 level2 lfo2">
<![if !supportLists]><span style="font-size:11.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: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><span style="font-size:11.0pt"><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">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).<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">Thoughts on this?<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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> v/r,<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>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><u><span style="font-size:10.0pt;color:black"><o:p><span style="text-decoration:none"> </span></o:p></span></u></p>
<p class="MsoNormal" style="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><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal" style="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><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal" style="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"><span style="color:#7F7F7F">kscott@mitre.org</span></a></span></b><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#474747"> </span></b><span style="font-size:10.0pt;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><span style="font-size:10.0pt;color:black"><a href="http://www.mitre.org/"><b><span style="color:blue">The MITRE Corporation</span></b></a><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7F7F7F">M/S J500</span></b><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7F7F7F">7515 Colshire Drive</span></b><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7F7F7F">McLean, VA 22102</span></b><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal" style="line-height:14.0pt;text-autospace:none"><b><span style="font-size:10.0pt;color:#7F7F7F"> </span></b><span style="font-size:10.0pt;color:#7F7F7F"><o:p></o:p></span></p>
<p class="MsoNormal"><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/"><span style="color:#7F7F7F">https://www.mitre.org/tech/mii/pki/</span></a></span></b><span style="font-size:10.0pt;color:#7F7F7F"><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"><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"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>