<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=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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:Consolas;
        panose-1:2 11 6 9 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:"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;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
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.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@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">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I am just now catching up on email threads in preparation for our teleconference.<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">With reference to the SDLS EP GVCID, it is indeed a concatenation of the longest defined versions of the respective fields (TFVN + SCID + VCID + MAPID if applicable). 
 The intention was for every SDLS EP implementation to have a standard, interoperable way to parse these values between Initiator and Recipient, for any combination of SLPs.  It would be possible to add a NOTE to that effect.  Since these values are logical
 bit fields taken from the Primary Header, I did not foresee them being used in mathematical operations where overflow conditions could be a problem.<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">As for inherent ambiguity, there is still the problem that TC and TM have the same TFVN (‘00’).  The solution to this problem was for the PDU itself to specify
 in the Service Group field (section 5.3.2.2.2.3…) whether the applicable SDLS link is Initiator-to-Recipient (‘01’) or Recipient-to-Initiator (‘10’).  With that, each end should have enough information locally to know whether TM or TC is the SLP used on the
 link.<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: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">Craig<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"><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"> SLS-SEA-DLS <sls-sea-dls-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>David Koisser (external)<br>
<b>Sent:</b> Monday, July 15, 2019 8:26 AM<br>
<b>To:</b> Gian.Paolo.Calzolari@esa.int<br>
<b>Cc:</b> SLS-SEA-DLS <sls-sea-dls-bounces@mailman.ccsds.org>; Lucas, John P. (GSFC-5960) <john.p.lucas@nasa.gov>; Matt Cosby <matt.cosby@goonhilly.org>; "sls-sea-dls@mailman.ccsds.org"@esa.int<br>
<b>Subject:</b> [EXTERNAL] Re: [Sls-sea-dls] SDLS EP GVCID Issues<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi Gian Paolo,</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">As you said, it needs to be implemented "with some caution". However, I think standards should either avoid pitfalls like this entirely (if possible) or hint at them *very* clearly. It should be
 crystal clear how to process frames. This is especially true for a security standard.
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I don't think the current version does enough to hint at the inherent ambiguity of the GVCID, which took me quite a while to actually notice.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Cheers,</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">David</span> <br>
<br>
<br>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Gian Paolo Calzolari/esoc/ESA</span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"David Koisser (external)" <<a href="mailto:David.Koisser@esa.int">David.Koisser@esa.int</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Lucas, John P.\(GSFC-5960\)" <<a href="mailto:john.p.lucas@nasa.gov">john.p.lucas@nasa.gov</a>>, "SLS-SEA-DLS"
 <<a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org">sls-sea-dls-bounces@mailman.ccsds.org</a>>, "<a href="mailto:sls-sea-dls@mailman.ccsds.org">sls-sea-dls@mailman.ccsds.org</a>", "Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>>,
 "Matt Cosby" <<a href="mailto:matt.cosby@goonhilly.org">matt.cosby@goonhilly.org</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">15/07/2019 11:04</span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [Sls-sea-dls] SDLS EP GVCID Issues</span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal"><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">David,</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">        I am mot sure I fully capture your issue/doubts.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">There are indeed different definitions sometimes coming ether from real difference (TM and AOS do not have MAPs) or from some different terminology for historical reasons.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">The general definition is indeed GVCID = TFVN + SCID + VCID & GMAPID = TFVN + SCID + VCID + MAPID with the caveat that the MAP Identifies may not exist and that the total length depends on the applied
 standard.</span> <br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Implementers need to implement it with some caution.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">The mapping between USLP and Proximity is due - as far as I remember - that Proximity-1 never really defined a GVCID.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Greg & Matt, copied here, may add more comments.</span>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Note also tat there a pending corrigendum (not yet on web but approved) for  CCSDS 320.0-M-7    CCSDS Spacecraft Identification Field Code Assignment Control Procedures. Magenta Book. Issue 7. November
 2017.</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards</span> <br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Gian Paolo</span> <br>
<br>
<br>
<br>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"David Koisser (external)" <<a href="mailto:David.Koisser@esa.int">David.Koisser@esa.int</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif"><a href="mailto:%22sls-sea-dls@mailman.ccsds.org%22@esa.int">"sls-sea-dls@mailman.ccsds.org"@esa.int</a></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Lucas, John P.\(GSFC-5960\)" <<a href="mailto:john.p.lucas@nasa.gov">john.p.lucas@nasa.gov</a>></span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">15-07-19 10:21</span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">[Sls-sea-dls] SDLS EP GVCID Issues</span>
<br>
<span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Sent by:        </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"SLS-SEA-DLS" <<a href="mailto:sls-sea-dls-bounces@mailman.ccsds.org">sls-sea-dls-bounces@mailman.ccsds.org</a>></span>
<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hello everyone,</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
We noticed some more issues regarding the GVCID / MAPID. After checking, it turns out different standards have very different interpretations. I attached screenshots of the regarding sections of the blue books for your convenience.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
The SDLS EP GVCID seems to be an aggregate of the longest defined versions of the respective fields. To my knowledge SDLS EP seems to be the only and first document, which specifically defines a (merged) GVCID. All other standards only define them as GVCID
 = TFVN + SCID + VCID & GMAPID = TFVN + SCID + VCID + MAPID (without sizes). In USLP the relation between old and new frames is defined, but only for Proximity-1 (see C1.1). I am not sure if this is more clearly explained somewhere else.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
In SDLS EP I see two problems. First, there is no explanation or justification for the lengths. Second, this may possibly lead to severe bugs, e.g. overflowing a TM VCID bigger than what fits in the defined 3 bits, like 16 bits in USLP or worse, 6 bits in TC
 (with identical TFVN as TM). Improper sanity checks here may even lead to security critical bugs.</span>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Cheers,</span> <span style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
David</span> <br>
<br>
<tt>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</tt><span style="font-family:"Courier New""><br>
<tt>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</tt><br>
<tt>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</tt><br>
<tt>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).</tt><br>
<tt>[attachment "USLP.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "TM.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "TC.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "Segment.PNG" deleted by Gian Paolo Calzolari/esoc/ESA]
 [attachment "SDLS EP.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] </tt></span><br>
<tt><span style="font-size:10.0pt">_______________________________________________</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>SLS-SEA-DLS mailing list</tt><br>
<tt><a href="mailto:SLS-SEA-DLS@mailman.ccsds.org">SLS-SEA-DLS@mailman.ccsds.org</a></tt><br>
</span><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.ccsds.org_cgi-2Dbin_mailman_listinfo_sls-2Dsea-2Ddls&d=DwMBAg&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=Oep7ohNtmOtgCLnOM0ruvOjNH5r6sRiImpa4QFCB8C_KZc7EsCiEKTRKioDx_csa&m=MRuxhprpUMmV13IxrHKfCYlJC32hTzLCiOoUddI9PG0&s=cxp8-lGdViS2KgPipXvMlPxaDdAjpkiKgPPHddIc3D0&e="><tt><span style="font-size:10.0pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
</span><br>
<br>
<o:p></o:p></p>
<pre>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).<o:p></o:p></pre>
</div>
</body>
</html>