<span style=" font-size:10pt;font-family:sans-serif">Hi Gian Paolo,</span>
<br>
<br><span style=" font-size:10pt;font-family: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:10pt;font-family: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:10pt;font-family:sans-serif">Cheers,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">David</span>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">Gian
Paolo Calzolari/esoc/ESA</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"David
Koisser (external)" <David.Koisser@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"Lucas,
John P.\(GSFC-5960\)" <john.p.lucas@nasa.gov>, "SLS-SEA-DLS"
<sls-sea-dls-bounces@mailman.ccsds.org>, "sls-sea-dls@mailman.ccsds.org",
"Kazz, Greg J (313B)" <greg.j.kazz@jpl.nasa.gov>, "Matt
Cosby" <matt.cosby@goonhilly.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">15/07/2019
11:04</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">Re:
[Sls-sea-dls] SDLS EP GVCID Issues</span>
<br>
<hr noshade>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">David,</span>
<br><span style=" font-size:10pt;font-family:sans-serif">
I am mot sure I fully capture your issue/doubts.</span>
<br><span style=" font-size:10pt;font-family: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:10pt;font-family: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:10pt;font-family:sans-serif">Implementers need
to implement it with some caution.</span>
<br>
<br><span style=" font-size:10pt;font-family: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:10pt;font-family:sans-serif">Greg & Matt,
copied here, may add more comments.</span>
<br>
<br><span style=" font-size:10pt;font-family: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:10pt;font-family:sans-serif">Regards</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Gian Paolo</span>
<br>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"David
Koisser (external)" <David.Koisser@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"sls-sea-dls@mailman.ccsds.org"@esa.int</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"Lucas,
John P.\(GSFC-5960\)" <john.p.lucas@nasa.gov></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">15-07-19
10:21</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">[Sls-sea-dls]
SDLS EP GVCID Issues</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent
by: </span><span style=" font-size:9pt;font-family:sans-serif">"SLS-SEA-DLS"
<sls-sea-dls-bounces@mailman.ccsds.org></span>
<br>
<hr noshade>
<br>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Hello everyone,</span><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family: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><span style=" font-size:12pt"> <br>
</span><span style=" font-size:10pt;font-family: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><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family: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><span style=" font-size:12pt">
<br>
</span><span style=" font-size:10pt;font-family:sans-serif"><br>
Cheers,</span><span style=" font-size:12pt"> </span><span style=" font-size:10pt;font-family:sans-serif"><br>
David</span><span style=" font-size:12pt"> <br>
</span>
<br><tt><span style=" font-size:12pt">This message is intended only for
the recipient(s) named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination
is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies
appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA
Data Protection Officer (dpo@esa.int).<br>
[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]
</span></tt>
<br><tt><span style=" font-size:10pt">_______________________________________________<br>
SLS-SEA-DLS mailing list<br>
SLS-SEA-DLS@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt>
<br>
<br>
<br><PRE>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 (dpo@esa.int).
</PRE>