<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:"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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.m4464861483782831733msolistparagraph, li.m4464861483782831733msolistparagraph, div.m4464861483782831733msolistparagraph
{mso-style-name:m_4464861483782831733msolistparagraph;
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.m4464861483782831733m313055847690544806msoplaintext, li.m4464861483782831733m313055847690544806msoplaintext, div.m4464861483782831733m313055847690544806msoplaintext
{mso-style-name:m_4464861483782831733m313055847690544806msoplaintext;
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.m4464861483782831733gmailsignatureprefix
{mso-style-name:m_4464861483782831733gmailsignatureprefix;}
span.gmailsignatureprefix
{mso-style-name:gmail_signature_prefix;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></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=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>That’s right. We don’t have any specs for anycast at this point, but we could start thinking about that once we get some agreement on multicast.<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'>ION currently only allows a given endpoint to be open for reception by one process at a time. But that’s an artifact of early ION design which we could probably move beyond. We would want to somehow make sure the processes receiving data at that endpoint are cooperative, but that seems doable.<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'>Scott<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><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;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org> <b>On Behalf Of </b>Birrane, Edward J. via SIS-DTN<br><b>Sent:</b> Tuesday, May 23, 2023 9:22 PM<br><b>To:</b> Vint Cerf <vint@google.com><br><b>Cc:</b> sis-dtn@mailman.ccsds.org; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson@jpl.nasa.gov><br><b>Subject:</b> Re: [Sis-dtn] [EXT] Re: [EXTERNAL] IPN URI Scheme Service Numbers<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;font-family:"Calibri",sans-serif;color:#1F497D'>Good point – I see no reason why a node couldn’t handle multiple service users simultaneously. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>And it probably bears repeating:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Service numbers are neither port numbers nor PIDs. And an IPN URI is an identifier not an address. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Even if a node spawns multiple processes to load-balance a service that doesn’t imply extra service numbers.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>-Ed<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Edward J. Birrane, III, Ph.D. (he/him/his)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Chief Engineer, Space Constellation Networking<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Supervisor, Embedded Applications Group <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Space Exploration Sector<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Johns Hopkins Applied Physics Laboratory<br>(W) 443-778-7423 / (C) 443-690-8272</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><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;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Vint Cerf <<a href="mailto:vint@google.com">vint@google.com</a>> <br><b>Sent:</b> Wednesday, May 24, 2023 12:16 AM<br><b>To:</b> Birrane, Edward J. <<a href="mailto:Edward.Birrane@jhuapl.edu">Edward.Birrane@jhuapl.edu</a>><br><b>Cc:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov">jordan.l.torgerson@jpl.nasa.gov</a>>; <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> Re: [EXT] Re: [Sis-dtn] [EXTERNAL] IPN URI Scheme Service Numbers<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>is there some reason a DTN node cannot serve multiple users with the same service concurrently?<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>v<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, May 24, 2023 at 7:10 AM Birrane, Edward J. <<a href="mailto:Edward.Birrane@jhuapl.edu">Edward.Birrane@jhuapl.edu</a>> wrote:<o:p></o:p></p></div><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><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Yeah,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> I have no issue with standard numbers for services, either. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> I *<b>think</b>* the reasoning against standardized service numbers is fourfold:</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=m4464861483782831733msolistparagraph><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>1.</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>We don’t seem to be using them. The SANA registry only standardizes 64/65 for CFDP sender/receiver. Even then, there was some concern about nodes that have multiple instances of CFDP engines running (IIRC).</span><o:p></o:p></p><p class=m4464861483782831733msolistparagraph><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=m4464861483782831733msolistparagraph><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>2.</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Service numbers might be domain dependent. If we reserve a number (or two) for CFDP, that’s probably a good thing for the space domain but not for other domains that would never use CFDP. Should we be reserving “universal” service number space for services that are not universal?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=m4464861483782831733msolistparagraph><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>3.</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Every BPA would need to protect service number ranges that are for things they would never use.</span><o:p></o:p></p><p class=m4464861483782831733msolistparagraph><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=m4464861483782831733msolistparagraph><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>4.</span><span style='font-size:7.0pt;color:#1F497D'> </span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>On the internet most well-known ports aren’t used anymore and we use single ports (like 443) for different kinds of traffic and rely on service discovery. Especially in microservice architectures? (not my area so unsure on this one)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> But the alternative is service discovery over a DTN (sounds like a bad idea) or adding an extension block with service info (which is kinda back to service numbers).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> Since the service number space is large (64bit) it seems like a small ask to carve out a few 2-byte and 3-byte ranges for standard services.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>-Ed</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Edward J. Birrane, III, Ph.D. (he/him/his)</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Chief Engineer, Space Constellation Networking</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Supervisor, Embedded Applications Group </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Space Exploration Sector</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Johns Hopkins Applied Physics Laboratory<br>(W) <a href="tel:(443)%20778-7423" target="_blank">443-778-7423</a> / (C) <a href="tel:(443)%20690-8272" target="_blank">443-690-8272</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><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'><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 <<a href="mailto:vint@google.com" target="_blank">vint@google.com</a>> <br><b>Sent:</b> Tuesday, May 23, 2023 10:18 PM<br><b>To:</b> Torgerson, J. Leigh (US 332C) <<a href="mailto:jordan.l.torgerson@jpl.nasa.gov" target="_blank">jordan.l.torgerson@jpl.nasa.gov</a>><br><b>Cc:</b> Birrane, Edward J. <<a href="mailto:Edward.Birrane@jhuapl.edu" target="_blank">Edward.Birrane@jhuapl.edu</a>>; <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> [EXT] Re: [Sis-dtn] [EXTERNAL] IPN URI Scheme Service Numbers</span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I agree with Torgerson's reasoning.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>v<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Tue, May 23, 2023 at 11:40 PM Torgerson, J. Leigh (US 332C) via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a>> wrote:<o:p></o:p></p></div><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><div><p class=m4464861483782831733m313055847690544806msoplaintext>I generally agree with the proposal Ed outlines (though I would like to reserve all 1 or 2 byte SN’s as standards, and leave the private use service numbers for the 3 or 4-byte encodings, much like the convention of the first 1024 IP well-known ports, since everyone should want to be using standard application services like bping, other snmp-like applications, and for deep space use, CDFP at least.. Standard 1 or 2 byte service numbers for the most common applications would be more efficient.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Why not all private? If a program (say, the Mars program) wants all nodes to be able to host a CFDP client that identifies itself as service number 65, then if a mission is launched later, and it wants to relay CFDP data through one of the other Mars nodes, then it will have to use service number 65, or arrange with other nodes to use some other service number, which will take intervention by the operators of the other nodes. <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>This is the primary operational need to agree on some standard conventions for service numbers. I don’t think you want every DTN node in an IPN network to be able to pick its own service number for each application. (Some underlying convergence layer choices in a relay situation may depend on knowledge of the application so the correct convergence layer may be chosen for the next hop, and if the service numbers aren’t standardized, it will be a crap shoot at any relay node.)<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>We’re trying to create an easily-interoperable DTN-enabled network, and I don’t see why standardized service numbers are controversial. Is it a matter of food-fights between “registry organizations”? Is it a matter of how many bytes you use because of the CBOR encoding? IDK, but I do think making service numbers all “private” is a really bad idea – it just kicks the can down the road and leaves room for a lot of chaos as the SSI and DTN scale up.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Leigh<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext><span style='font-family:"Tahoma",sans-serif'></span>On 5/22/23, 5:49 AM, "SIS-DTN on behalf of Birrane, Edward J. via 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 <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>>> wrote:<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>WG,<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Last week at the SIS-DTN weekly meeting we had a good discussion on allocation strategies for IPN service numbers. <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>IIRC, there were three major areas of discussion related to these numbers: encoding size, allocation policy, and registry ownership.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>The encoding size discussion noted that the CBOR encoding of service numbers creates a very small allocation of 1-byte encodings (0-23), a small allocation of 2-byte encodings (24-155), a moderate size allocation of 3-byte encodings (256-65,535), and then 4+ byte encodings that give us the remainder of the 64bit service number space.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>The allocation policy discussion noted that there was a good case for "private use" service numbers for mission-specific use cases (commanding, telemetry) that do not otherwise map to a standardized protocol. These mission specific service numbers should not be standardized (they are mission specific) and there should be some allowance for them in the small encoding space since they will be used by missions often (perhaps most often).<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>The registry ownership discussion noted that IANA is creating (updating really..) a registry for service numbers and should there be a SANA allocation in that registry.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>At the end of the discussion the following proposal was put forward:<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>1 byte service numbers (1-23) will be private use .<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>2 byte service numbers (24-255) will be expert review with a 64-id chunk allocated to SANA.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>3 byte service numbers (256-65k) will be cut 1/3 private use, 1/3 IANA managed and 1/3 IANA managed but given to SANA.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>4 byte will have a chunk of experimental.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>4+bytes is unassigned. <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>This continues to be an area of active discussion in the IETF mailing list. Some IETF participants are proposing that all service numbers be private-use and there be no standard service numbers since service discovery is better done today independent of port numbers. I disagree with this position - service numbers are not port numbers - but that case needs to be made, for those interested in following the discussion on the IETF mailing list.<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>-Ed<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>---<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Edward J. Birrane, III, Ph.D. (he/him/his)<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Chief Engineer, Space Constellation Networking<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Supervisor, Embedded Applications Group<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Space Exploration Sector<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>Johns Hopkins Applied Physics Laboratory<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>(W) <a href="tel:(443)%20778-7423" target="_blank">443-778-7423</a> / (F) <a href="tel:(443)%20228-3839" target="_blank">443-228-3839</a><o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>_______________________________________________<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext>SIS-DTN mailing list<o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext><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>><o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$" target="_blank">https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$</a> <<a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$" target="_blank">https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$</a>> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p><p class=m4464861483782831733m313055847690544806msoplaintext> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<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><o:p></o:p></p></div></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br clear=all><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span class=m4464861483782831733gmailsignatureprefix>-- </span><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Please send any postal/overnight deliveries to:<o:p></o:p></p></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Vint Cerf<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Google, LLC<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>1900 Reston Metro Plaza, 16th Floor<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Reston, VA 20190<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a href="tel:(571)%20213-1346" target="_blank">+1 (571) 213 1346</a><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>until further notice<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div></div></div></blockquote></div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><span class=gmailsignatureprefix>-- </span><o:p></o:p></p><div><div><div><p class=MsoNormal>Please send any postal/overnight deliveries to:<o:p></o:p></p></div><div><div><p class=MsoNormal>Vint Cerf<o:p></o:p></p></div><div><p class=MsoNormal>Google, LLC<o:p></o:p></p></div><div><p class=MsoNormal>1900 Reston Metro Plaza, 16th Floor<o:p></o:p></p></div><div><p class=MsoNormal>Reston, VA 20190<o:p></o:p></p></div><div><p class=MsoNormal>+1 (571) 213 1346<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>until further notice<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></body></html>