<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)">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.E-MailFormatvorlage18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.E-MailFormatvorlage20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:747390201;
mso-list-template-ids:-1327336976;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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">Yes, but the only concern I have is that removing the SDA feature currently appearing in Section 7.2 will have also an impact on the PICS section that shows SDA as mandatory currently. As such I’m afraid that it won’t just be a corrigendum
but really a pink sheet. According to the CCSDS yellow book about the processes, a corrigendum is about minor technical changes, whatever it may mean. I can check again with Tom what are the boundaries of “minor technical changes” just not to waste too much
time.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Tomaso<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="DE">Von:</span></b><span lang="DE"> Felix Flentge <Felix.Flentge@esa.int>
<br>
<b>Gesendet:</b> Donnerstag, 22. Juni 2023 10:50<br>
<b>An:</b> sburleig.sb@gmail.com; 'Sanchez Net, Marc (US 332H)' <marc.sanchez.net@jpl.nasa.gov>; 'Keith Scott' <keithlscott@gmail.com>; de Cola, Tomaso <Tomaso.deCola@dlr.de><br>
<b>Cc:</b> sis-dtn@mailman.ccsds.org<br>
<b>Betreff:</b> RE: [Sis-dtn] [EXTERNAL] Re: Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB">We may be back to the discussion what happens if we remove a feature. IMHO, the clean solution would be to remove the SDA from current LTP because it is not sufficient to specify an interoperable mechanism (furthermore,
I believe the design that LTP SDA needs to know something about the different types of service data which may be aggregated is not a good one). We can also argue that for BPv7 there is no problem and that the BPv7 BB will specify aggregation of bundles in
LTP (and updated CFDP magenta book will do as well). Existing implementations will remain fully LTP compliant it is just that using BP(v6) / LTPCL may be viewed as BP(v6) / SDACL / LTP with a not-standardised SDACL.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>sburleig.sb--- via SIS-DTN<br>
<b>Sent:</b> Wednesday, June 21, 2023 9:18 PM<br>
<b>To:</b> 'Sanchez Net, Marc (US 332H)' <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>; 'Keith Scott' <<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>>; 'Tomaso de Cola' <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> Re: [Sis-dtn] [EXTERNAL] Re: Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">No, the issue is not the block size; that’s clearly defined in the specification. The issue is being able to determine the lengths of all the individual client data units that are aggregated in the block.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">That is easily determined if the client is BP, because each bundle’s size is self-identifying. But suppose the client is Email? How does the LTP engine that receives this LTP block figure out where one of the
aggregated emails ends and the next one begins? That method must be defined somewhere, and the receiving engine can use the client ID – once it is registered with SANA – to look up the parsing method. But that’s beyond the scope of this specification.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">What Felix is suggesting is, more or less, that each client data unit in the block could be preceded by a 32-bit unsigned integer giving the length of that client data unit, regardless of client ID. This would
be a general mechanism, imposing some additional overhead cost, which is NOT included in the LTP spec. We need not talk about it.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Scott<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b>From:</b> Sanchez Net, Marc (US 332H) <<a href="mailto:marc.sanchez.net@jpl.nasa.gov">marc.sanchez.net@jpl.nasa.gov</a>>
<br>
<b>Sent:</b> Wednesday, June 21, 2023 12:05 PM<br>
<b>To:</b> <a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; 'Keith Scott' <<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>>; 'Tomaso de Cola' <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> RE: [EXTERNAL] Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Looking at table C-1, it seems that there are two parameters related to SDA aggregation, size and time. If I understand this correctly, the problem with the current spec only applies when the LTP block is released
because the SDA Aggregation timer expires (if the size limit is reached, then no problem, the size of the block is already specified in Table C-1 and thus is a managed parameters known to the receiver). Is that the correct interpretation? If so, I am not sure
we can simply say “that the information needed to delimit the aggregated data units in the SDA structure is beyond the scope of the specification” because it is at least partially already in the specification MIB.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Maybe the solution is to add a note in 7.2.3.4.1.3 saying that implementations may find it useful to pad all LTP blocks released due to time limit reached with enough zeros to complete the LTP block size as specified
in Table C-1? But does that really solve the problem? How will the rx know when data ends and padding zeroes start…<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Marc Sanchez Net (332H)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:10.0pt;color:gray">Telecommunications Engineer</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span style="font-size:10.0pt;color:gray">Jet Propulsion Laboratory<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt;background:white"><span style="font-size:10.0pt;color:gray">Cell:</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black"><a href="mailto:(617)%20953-7977"><span style="color:#0563C1">(617)
953-7977</span></a></span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span style="font-size:10.0pt;color:gray">|</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0">
</span><span style="font-size:10.0pt;color:gray">Email:</span><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222"> </span><span style="color:black"><a href="mailto:marc.sanchez.net@jpl.nasa.gov"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">marc.sanchez.net@jpl.nasa.gov</span></a></span><span style="font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>sburleig.sb--- via SIS-DTN<br>
<b>Sent:</b> Wednesday, June 21, 2023 7:08 AM<br>
<b>To:</b> 'Keith Scott' <<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>>; 'Tomaso de Cola' <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> [EXTERNAL] Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Right, I think it’s not that the specification is not interoperable, only that the nature of the client data units – including the information needed to delimit the aggregated data units in the SDA structure –
is identified by the client ID; that registration is beyond the scope of the specification.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt">Scott<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-left:36.0pt"><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Keith Scott via SIS-DTN<br>
<b>Sent:</b> Wednesday, June 21, 2023 2:36 AM<br>
<b>To:</b> Tomaso de Cola <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">Mmmm.... will try to find the right words. <o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"> -keith<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt">On Wed, Jun 21, 2023, 10:48 AM <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
Hi Keith,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
Thank you for the summarized discussion on LTP-corrigendum. <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
Just one consideration about SDA aggregation (point 7 in the list). The description seems to point about the fact that the current specification of the mechanism does not allow interoperability because of the lack of information of the client data unit, which
is I think agreed and well understood. I’d however try to find a “smarter” way to say this, since having a specification which has a non-interoperable feature will not be accepted by CESG and this will cause endless iterations and discussions there before
getting the green light.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
Regards,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
Tomaso<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<b><span lang="DE">Von:</span></b><span lang="DE"> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>>
<b>Im Auftrag von </b>Keith Scott via SIS-DTN<br>
<b>Gesendet:</b> Dienstag, 20. Juni 2023 18:35<br>
<b>An:</b> <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br>
<b>Betreff:</b> [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
LTP Corrigendum (from the telecon last Thursday):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Discussed the latest JPL collection of issues here (<a href="https://urldefense.us/v3/__https:/cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc=*7bA52D5D6D-7A66-4CCD-AB61-B215AA2B8C36*7d&file=Draft*20LTP*20corrigendum*20-*20JPL*20edits*20(1).docx&action=default__;JSUlJSUlJSU!!PvBDto6Hs4WbVuu7!LCeuTfHRA-LEWR-KvEDLe0i6i_hNmJSv6s71tkiKsE8GF9G2WuONw5VgyJ3VhoHWAzOx4uoYfTZbeHQbcqsxLE9Ue77kmlg$" target="_blank">https://cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc={A52D5D6D-7A66-4CCD-AB61-B215AA2B8C36}&file=Draft%20LTP%20corrigendum%20-%20JPL%20edits%20(1).docx&action=default</a>)<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>We definitely want a CORRIGENDUM (non-normative, no changes to the protocol) NOT a set of Pink sheets or a Pink Book (which would/could be normative and would require agency review). So, all proposed text should be in the form
of non-normative suggestions to implementers.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>We discussed putting all of the proposed changes into a single location or spreading them throughout the document. The consensus was that it would be better for implementers to put the suggestions proximate to the places in the
document that discuss the protocol mechanisms (i.e. mixed throughout). Should ask Tom what he thinks of this...<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>Blue text in the document reflects the WG consensus on the telecon; we agreed that folks would propose final "copy-ready" text in green together with the location where that text should go.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
Added the CNES RIDs to the spreadsheet.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
--keith<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt">
<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-GB">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">dpo@esa.int</a>).
<o:p></o:p></span></p>
</div>
</body>
</html>