<span style=" font-size:10pt;font-family:sans-serif">Hello everyone,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<br><span style=" font-size:10pt;font-family:sans-serif">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>
<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><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>