<div dir="ltr">WHOIS was early on a manual directory<div>DNS did not exist - hosts.txt was manually created and disributed.</div><div><br></div><div>v</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 15, 2022 at 12:26 PM Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg3707489796140870280"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="m_3707489796140870280WordSection1"><p class="MsoNormal"><span style="font-size:11pt">I certainly favor transparency – we should tell folks what they need to do manually currently.  I’d LIKE to put that in a green book, like an updated SSI Architecture book, but if we need to add something to section 2 of the BPv7 profile that says something like the following, that’d probably work.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Here’s how to get a new node onto the BP network:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">1) Get a node number from SANA (to ensure that you don’t conflict with somebody else)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">2) Figure out who you want to connect to (immediate BP neighbor(s))<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="m_3707489796140870280MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">There’s not currently a good way of find out where the nodes are; you have to know somebody and figure out from there where there’s a good node for you to connect to.  MAYBE we should recommend that each center-equivalent with an agency/entity stand up a ‘border’ BP router?  That’d be a really good way to get stuff started.<u></u><u></u></span></li></ul><p class="MsoNormal"><span style="font-size:11pt">3a) Call somebody in charge of the nodes that you want to connect to to talk about convergence layers and contact plans and how to connect<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">3b) Talk to the folks with whom you want to communicate (endpoints) about security policy and other requirements.  <u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="m_3707489796140870280MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">Those endpoints may or may not implement BPsec, or may have other implementation-specific mechanisms (e.g. some sort of firewall-like capabilities)<u></u><u></u></span></li><li class="m_3707489796140870280MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">Eventually BPsec is coming, so be planning to go that way.<u></u><u></u></span></li></ul><p class="MsoNormal"><span style="font-size:11pt">3c) If you want to get information from ‘the network’ (network management) you’re going to need to work getting that information with the individual bp node managers (people).<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="m_3707489796140870280MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">Network management isn’t standardized yet (anywhere, CCSDS *<b>or</b>* IETF) so it’s likely that anything you’ll be able to get is going to be custom.<u></u><u></u></span></li></ul><p class="MsoNormal"><span style="font-size:11pt">4) Understand that this BP network we’re building is a network.  Once you connect to the network, anybody on the network will (probably) be able to send bundles to your node.<u></u><u></u></span></p><ul style="margin-top:0in" type="disc"><li class="m_3707489796140870280MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">BPsec, if you implement it and if you tighten your security policy, should mitigate risk here<u></u><u></u></span></li><li class="m_3707489796140870280MsoListParagraph" style="margin-left:0in"><span style="font-size:11pt">We need to develop firewall-like mechanisms in our implementations, or acquire other implementations that have them.<u></u><u></u></span></li></ul><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Is that the kind of thing you’re looking for?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">                                v/r,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">                                --keith<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in"><p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>><br><b>Date: </b>Tuesday, November 15, 2022 at 12:09 PM<br><b>To: </b>Cerf, Vinton <<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>>, Felix Flentge <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>>, Dr. Keith L Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>><br><b>Cc: </b>Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@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>Subject: </b>Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution<u></u><u></u></span></p></div><p class="MsoNormal"><span style="font-size:11pt">Vint, Felix, Keith, et al,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">I get the point about wanting to have this spec out sooner rather than later, and I am not trying to stall that event.  I do see these missing pieces as being part of the functional superstructure for the SSI and not service management (which in my mind includes contact planning and related configuration info), nor network management (which includes routing updates and controls).  I think that those can wait.  An important part of what is missing in my mind is the SSI equivalent of DNS and WhoIs, both of which, if I am not mistaken, were present in the early days of the Internet.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">In the case of the SSI we really do not have to create anything new to create some useful registries, we can just use what is there in the SANA already.  Perhaps wise council is to say that we might be jumping the gun by doing that and moving in a direction that, on further consideration, is not the long term direction we would want to go for our nascent Solar System Internet.   I can abide with that result, but I feel we are missing an obvious opportunity to start to govern this thing we are creating.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">If that is what consensus dictates that is fine.  But at that point I think we need to tell the cottage industry folks, in this SSI Stage 2a, that they must fend for themselves and cook up local / implementation-based solutions to manage node IDs, naming, identities and keys.  Or do you all think that we should just stay silent on that subject too?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt">Thanks, Peter<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in"><p class="MsoNormal"><b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">Vint Cerf <<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>><br><b>Date: </b>Tuesday, November 15, 2022 at 3:18 AM<br><b>To: </b>Felix Flentge <<a href="mailto:Felix.Flentge@esa.int" target="_blank">Felix.Flentge@esa.int</a>><br><b>Cc: </b>Keith Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>, Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>, "Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@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>Subject: </b>Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution</span><span style="font-size:11pt"><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt">Felix, thanks for pragmatic advice - it's really important to have blue book in hand for BPv7 sooner rather than later.<u></u><u></u></span></p><div><p class="MsoNormal"><span style="font-size:11pt">Operational experience will help us find the answers to dangling participles.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt">v<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div></div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p><div><div><p class="MsoNormal"><span style="font-size:11pt">On Tue, Nov 15, 2022 at 2:30 AM Felix Flentge via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>> wrote:<u></u><u></u></span></p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><p class="MsoNormal"><span style="font-size:11pt">All,<br><br>I think what we are discussing here belongs more to the 'realm' of service management and needs to consider at least the following aspects and the relationship between them:<br><br>  1.  CCSDS Service Management (upcoming) standards, in particular, the Service Catalogue (which may or may not be related to SS&A)<br>  2.  Functional Resource Model which could cover more dynamic aspects like configuration of some nodes<br>  3.  DTN Network Management<br><br>While I think it is important to have a plan how to address this topic (I would think that the CESG could discuss the how, who and when), I also would like to stress that this is IMHO not required for release of CCSDS BPv7 for Agency review. I see an urgent need to have a CCSDS BPv7 Blue Book out asap for upcoming programmes and projects. Of course, this book will not and cannot address all topics which are necessary for DTN in general (in the same way RfC 791 fails to describe a lot of things which are necessary for a planetary Internet) or even all aspects which are required for successful use in a single mission (e.g., accounting and reliability). These things will be addressed in upcoming standards and recommendations.<br><br>I am fine with the current (non-normative) text in 'D2 SANA Considerations', I am only wondering whether a special PoC for DTN would be necessary (there is already a generic PoC which would cover all services I assume). Anyway, I am happy with anything in this sections which is non-normative and allows us to move forward.<br><br>Regards,<br>Felix<br><br>From: SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>> On Behalf Of Dr. Keith L Scott via SIS-DTN<br>Sent: 14 November 2022 20:01<br>To: Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>; Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>; <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br>Subject: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution<br><br>Or maybe the human-in-the-loop is stage 2a and 2b is where the system is large enough that some automated lookup service is needed.  Honestly don't know if that's 'b' or 'd' or whatever, I think it's a function of the network size at which connecting to other nodes with human-in-the-loop gets unscalable.<br><br>                                --keith<br><br>From: SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>>> on behalf of Dr. Keith L Scott via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>Date: Monday, November 14, 2022 at 1:58 PM<br>To: Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a><mailto:<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a><mailto:<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>>, <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<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><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>Subject: Re: [Sis-dtn] [EXTERNAL] BPv7 PID resolution<br>To your first paragraph below: I think I agree, except that I was assuming that other sites (e.g. ground gateways between agencies) would be added to the SS&A registry as needed.  The 'unregistered nodes' in what you have below could be nodes entirely internal to some entity (e.g. a BP router 'in the middle of' NASA's infrastructure).  An entity could elect to instantiate a SS&A entries for all such nodes (e.g. build 17 room XXX of GSFC as a 'site' - OK, didn't actually check to see if the registry supports that well) if they want to.  We're not opposed to it, just wanted to admit the possibility that an agency might not want to list all such assets.<br><br>The intent of the above was that in stage 2b, the way to establish communication with something that's not yours would be to look up to POC in the SSI record in the SS&A registry and manually get the connectivity information.  That way nodes can be configured with 'default deny' security policies and (by the time the humans get through exchanging confiuguration information which would include security material) only accept bundles from trusted sources (using e.g. BPsec and a security context that signs the primary+payload blocks, e.g.)<br><br>We could devise some sort of directory service that would allow someone to query for the connectivity characteristics / configuration of a particular node, but I think that's: 1) not really needed at the moment / can be developed later as necessary 2) might require some interesting security measures (maybe I don't WANT just anybody to know how to communicate with this node, or even that the node exists) and 3) some more infrastructure around the information exchanges that will be needed (like a standardized way to express schedules).  I think the most relevant of those is 1) we can develop such a directory service later as needed.  We're better off getting a BPv7 spec out that folks can build to and as the population grows, think about automation.<br><br>                                --keith<br><br><br>From: Shames, Peter M (US 312B) <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a><mailto:<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>><br>Date: Monday, November 14, 2022 at 1:42 PM<br>To: Dr. Keith L Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a><mailto:<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>>, Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a><mailto:<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>>, <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<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><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>Subject: Re: [EXTERNAL] BPv7 PID resolution<br>Hi Keith,<br><br>I believe that there was a third aspect of this and that was providing an actual node registry and not just the existing "Agency x owns this range of node numbers", which is what we have now.  I assumed that all of the DTN Sites offering DTN services, i.e. store and forward, would be registered in the SS&A registry.  This would include who owned them, where they are located, what services they offer, and their node numbers.  That still leaves all of the rest of the DTN Nodes that do not offer services, per se, as essentially unregistered entities, except that their assigned number would (putatively) identify the "owning" agency.<br><br>In Stage 2a, where we are, more or less, expecting node deployments to be a private matter and managed by the agency (or project), the needed info about actual identities, locations, routing, etc must be managed (privately) within the deployment.  However, in any Stage 2b context, where interoperability and the identities of nodes, and their permissions, would be a concern, I wonder if this is really adequate?<br><br>Have you guys addressed this in any way?<br><br>Thanks, Peter<br><br><br>From: Keith Scott <<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a><mailto:<a href="mailto:kscott@mitre.org" target="_blank">kscott@mitre.org</a>>><br>Date: Monday, November 14, 2022 at 5:00 AM<br>To: Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a><mailto:<a href="mailto:peter.m.shames@jpl.nasa.gov" target="_blank">peter.m.shames@jpl.nasa.gov</a>>>, "Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a><mailto:<a href="mailto:beau.t.blanding@nasa.gov" target="_blank">beau.t.blanding@nasa.gov</a>>>, "<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><mailto:<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><mailto:<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>>><br>Subject: [EXTERNAL] BPv7 PID resolution<br><br>Peter,<br><br>The sis-dtn wg has gone through your comments on the bpv7 draft Red Book and has proposed modifications to the document to address the issues you raised.  The high-level proposed changes to the larger issues you raised are:<br><br><br>  *   Include text at the end of Section 2 identifying ongoing and future work that discusses security and network management, and how security can be used to secure network management.<br><br><br>  *   Include in the SANA considerations section a plan to use Site Service Info records in the Service Sites and Apertures registry to provide POC information to entities wishing to connect to the BP node at a specific site.<br><br><br>Some issues, like the 'late binding' discussion probably require some discussion to resolve.<br><br>Do you have some time to start working through the PID items?  The document is here: <a href="https://docs.google.com/document/d/1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p/edit?usp=share_link&ouid=112263620729744601172&rtpof=true&sd=true" target="_blank">https://docs.google.com/document/d/1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p/edit?usp=share_link&ouid=112263620729744601172&rtpof=true&sd=true</a><<a href="https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fdocs.google.com%2Fdocument%2Fd%2F1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p%2Fedit%3Fusp%3Dshare_link%26ouid%3D112263620729744601172%26rtpof%3Dtrue%26sd%3Dtrue__%3B!!PvBDto6Hs4WbVuu7!fmK28hRCJGziSKAiLWtldRMS9EO8YneHSoKu93EdeWZkVPN3SCYN5vaM29QgO89Mm8iaC6zB%24&data=05%7C01%7CFelix.Flentge%40esa.int%7C571a1469ceb2473f853408dac672d00b%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638040493666071731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W8kYhc20w8Ue261anPAgk2CEsq%2FDKV9lVfTVrUjun9k%3D&reserved=0" target="_blank">https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fdocs.google.com%2Fdocument%2Fd%2F1P8g8_2HPnadf3RfAdP6tltI4H_kwiL-p%2Fedit%3Fusp%3Dshare_link%26ouid%3D112263620729744601172%26rtpof%3Dtrue%26sd%3Dtrue__%3B!!PvBDto6Hs4WbVuu7!fmK28hRCJGziSKAiLWtldRMS9EO8YneHSoKu93EdeWZkVPN3SCYN5vaM29QgO89Mm8iaC6zB%24&data=05%7C01%7CFelix.Flentge%40esa.int%7C571a1469ceb2473f853408dac672d00b%7C9a5cacd02bef4dd7ac5c7ebe1f54f495%7C0%7C0%7C638040493666071731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W8kYhc20w8Ue261anPAgk2CEsq%2FDKV9lVfTVrUjun9k%3D&reserved=0</a>> if you'd like to take a look first, or we can start by walking through them together.<br><br>                                v/r,<br><br>                                --keith<br><br>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int" target="_blank">dpo@esa.int</a>).<br>_______________________________________________<br>SIS-DTN mailing list<br><a href="mailto:SIS-DTN@mailman.ccsds.org" target="_blank">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><u></u><u></u></span></p></blockquote></div><p class="MsoNormal"><span style="font-size:11pt"><br clear="all"><u></u><u></u></span></p><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div><p class="MsoNormal"><span style="font-size:11pt">-- <u></u><u></u></span></p><div><div><div><p class="MsoNormal"><span style="font-size:11pt">Please send any postal/overnight deliveries to:<u></u><u></u></span></p></div><div><div><p class="MsoNormal"><span style="font-size:11pt">Vint Cerf<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt">Google, LLC<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt">1900 Reston Metro Plaza, 16th Floor<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt">Reston, VA 20190<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"><a href="tel:(571)%20213-1346" value="+15712131346" target="_blank">+1 (571) 213 1346</a><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt">until further notice<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:11pt"> <u></u><u></u></span></p></div></div></div></div></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Please send any postal/overnight deliveries to:</div><div><div>Vint Cerf</div><div>Google, LLC</div><div>1900 Reston Metro Plaza, 16th Floor</div><div>Reston, VA 20190</div><div>+1 (571) 213 1346<br></div><div><br style="color:rgb(34,34,34)"></div></div><div><br></div><div>until further notice</div><div><br></div><div><br></div><div><br></div></div></div>