<font size=2 face="sans-serif">Dear Peter,</font>
<br><font size=2 face="sans-serif">        following
your conditions expressed in the attached commented pdf (instead of PIDs....)
please find here below the summary of the SEA conditions accepted by SLS
with mutual agreement as per previous exchange of mails.</font>
<br>
<br><font size=2 face="sans-serif">SLS AD and WG Chair position with respect
to any other change not listed below is that they deserve proper discussion
and participation at agency review and not now hiding them under the carpet
of the CESG Poll. </font>
<br><font size=2 face="sans-serif">Therefore RIDs may be issued during
Agency Review.</font>
<br>
<br><font size=2 face="sans-serif">I am confident we can proceed to CMC
Poll on this basis after CCSDS Editors implements the agreed changes.</font>
<br>
<br><font size=2 face="sans-serif">I wish you all a nice week end.</font>
<br>
<br><font size=2 face="sans-serif">Gian Paolo</font>
<br>
<br><font size=2 face="sans-serif">-------------------------------------------------------------------------------------------</font>
<br><font size=4 face="sans-serif"><b>SEA conditions accepted by SLS</b></font><font size=2><br>
[1] -------------------------------------------------------------------------------------------------</font><font size=3 face="Times New Roman">
</font><font size=2><b><br>
Section 2.3.1</b> -</font><font size=2 color=#800080> </font><font size=2><b> </b></font><font size=2 color=blue><u>SLS
Proposed change to</u>: When LDPC encoding of a stream of Channel Access
Data Units (CADUs) is performed, the sending end does codeword randomization
and attachment of Code Sync Marker as detailed in section 8.</font><font size=3 face="Times New Roman">
</font><font size=2><b><br>
Section 2.3.1</b> -</font><font size=2 color=#800080> </font><font size=2><b><u> </u></b></font><font size=2 color=blue><u>PS
Proposed change to</u>: When LDPC encoding of a stream of Channel Access
Data Units (CADUs) is performed, the sending end does codeword randomization
and attachment of Code Sync Marker as </font><font size=2 color=red><b>described</b>
</font><font size=2 color=blue>in section 8 </font><font size=2 color=red><b>and
shown explicitly in Figure 8-2</b></font><font size=2 color=blue>.</font><font size=3 face="Times New Roman">
</font><font size=2 color=#800080><b><br>
No problem with PS further proposal.</b></font><font size=3 face="Times New Roman">
</font><font size=2><b> </b></font>
<br><font size=2><b>AGREED TO CHANGE TO</b>: <b>(Section 2.3.1) </b></font><font size=2 color=blue>When
LDPC encoding of a stream of Channel Access Data Units (CADUs) is performed,
the sending end does codeword randomization and attachment of Code Sync
Marker as </font><font size=2 color=red><b>described</b> </font><font size=2 color=blue>in
section 8 </font><font size=2 color=red><b>and shown explicitly in Figure
8-2</b></font><font size=2 color=blue>.</font><font size=3 face="Times New Roman">
</font><font size=2><b><br>
[2] -----------<br>
Comment to Figure 2-2</b>: The text before the figure explains that CSM
insertion etc. is included in the LDPC encoding of a stream of CADUs. It
may be worth to complete that sentence stating "</font><font size=2 color=blue>and
for this reason is not explicitly shown in Figure 2-2</font><font size=2>."</font><font size=3 face="Times New Roman">
</font><font size=2 color=red><b><br>
Not required.  See change to 2.3.1.  Providing an explicit reference
to a descriptive figure is much more useful than saying “it’s not found
here.”</b></font><font size=3 face="Times New Roman"> </font><font size=2 color=#800080><b><br>
No problem with PS further proposal.</b></font><font size=3 face="Times New Roman">
</font>
<br><font size=2><b>AGREED NOT TO CHANGE Figure 2-2</b> after accepted
change in <b>Section 2.3.1</b>.<b><br>
[3] ----------<br>
Section 2.3.2</b> - </font><font size=2 color=blue>Proposed change to:
When LDPC decoding of a stream of CADUs  is performed, the receiving
end does Code Sync Marker detection and codeword derandomization as detailed
in section 8. </font><font size=2><b><br>
Section 2.3.2</b> - </font><font size=2 color=blue>Proposed change to:
When LDPC decoding of a stream of CADUs  is performed, the receiving
end does Code Sync Marker detection and codeword derandomization as </font><font size=2 color=red><b>described</b>
</font><font size=2 color=blue>in section 8 </font><font size=2 color=red><b>and
shown explicitly in Figure 8-2</b></font><font size=2 color=blue>.  </font><font size=2><b>
  </b></font><font size=2 color=#800080><b><br>
No problem with PS further proposal.</b></font><font size=3 face="Times New Roman">
</font>
<br><font size=2><b>AGREED TO CHANGE TO</b>: <b>(Section 2.3.2</b>)</font><font size=2 color=blue>
When LDPC decoding of a stream of CADUs  is performed, the receiving
end does Code Sync Marker detection and codeword derandomization as </font><font size=2 color=red><b>described</b>
</font><font size=2 color=blue>in section 8 </font><font size=2 color=red><b>and
shown explicitly in Figure 8-2</b></font><font size=2 color=blue>. </font><font size=2><b><br>
[4] ------------<br>
Comment to Figure 2-3</b>: As for Figure 2-2, it may be worth to complete
that sentence stating "</font><font size=2 color=blue>and for this
reason is not explicitly shown in Figure 2-3.</font><font size=2>"
or simply "</font><font size=2 color=blue>and it is not shown in Figure
2-3</font><font size=2>."</font><font size=3 face="Times New Roman">
</font><font size=2><b><br>
</b></font><font size=2 color=red><b>Not required.  See change to
2.3.2.  Providing an explicit reference to a descriptive figure is
much more useful than saying “it’s not found here.”</b></font><font size=3 face="Times New Roman">
</font><font size=2 color=#800080><b><br>
No problem with PS further proposal.</b></font><font size=3 face="Times New Roman">
</font>
<br><font size=2><b>AGREED NOT TO CHANGE Figure 2-</b>3 after accepted
change in <b>Section 2.3.2</b>.<b><br>
[5] ------------------<br>
Section 8.1</b> - Fine changing to "</font><font size=2 color=#000080>at
sending end</font><font size=2>".     </font><font size=2 color=#800080><b>Accepted
by everybody. </b></font><font size=2><b><br>
[6] ------------------<br>
Section 8.2.1</b> - Fine changing to "</font><font size=2 color=blue>at
receiving end</font><font size=2>".     </font><font size=2 color=#800080><b>Accepted
by everybody. </b></font><font size=2><b><br>
[7] ---------------------<br>
Section 8.2.7 and Figure 8-2</b> - Indeed harmonisation between receiving
end and receiving side shall be carried out. <b>Tom Gannett</b> proposes
a global change From</font><font size=3 face="Times New Roman"> </font><font size=2><br>
"receive side" and "receiving side"</font><font size=3 face="Times New Roman">
</font><font size=2> <br>
to: "receiving end".</font><font size=3 face="Times New Roman">
</font><font size=2 color=#800080><b><br>
Accepted by everybody.</b></font><font size=3 face="Times New Roman"> </font><font size=2><b><br>
[8] -------------------<br>
9.1.2</b> - OK typo to be corrected.          
     </font><font size=2 color=#800080> <b>Accepted by everybody.</b></font><font size=3 face="Times New Roman">
</font><font size=2><b><br>
[9] ----------------<br>
9.3.3</b> - <b>Tom Gannett</b> proposes to change from:   ."data
that applies LDPC coding of a transfer frame"</font><font size=3 face="Times New Roman">
</font><font size=2><br>
To</font><font size=3 face="Times New Roman"> </font><font size=2> 
"data that is LDPC coded as the result of applying LDPC coding to
a transfer frame"</font><font size=3 face="Times New Roman"> </font><font size=2><br>
+ (similar changes to 9.3.4 and 9.3.5)</font><font size=3 face="Times New Roman">
</font><font size=2 color=#800080><b><br>
Accepted by everybody.</b></font><font size=3 face="Times New Roman"> </font><font size=2><b><br>
[10] -----------<br>
10.2</b> - It may be improved as follows: "NOTE - This subsection
(including figure 10-1) does not apply to the case of LDPC encoding of
a stream of CADUs, where a CSM (and not an ASM) is added </font><font size=2 color=blue>and
randomization is applied according to  8.4 and figure 8-3</font><font size=2>.</font><font size=3 face="Times New Roman">
</font><font size=2 color=#800080><b><br>
Accepted by everybody.</b></font><font size=3 face="Times New Roman"> </font><font size=2><b><br>
[11] -----------<br>
Section 11.9 </b>- The requirement is needed as long as USLP frames are
not approved. It may change later.<b> </b></font><font size=2 color=blue><b>No
change for the time being</b></font><font size=2>.<b> </b></font><font size=2 color=#800080><b> 
 Accepted by everybody.</b></font><font size=3 face="Times New Roman">
</font><font size=2><b><br>
[12] -----------<br>
Table 12-6</b>: "Codeblock length" is used throughout the document..
<b>Tom</b> proposes leaving it alone. Peter further comments: </font><font size=2 color=red><b><br>
In Sec 4.3.5, 4.3.7 and in Sec 10.5.4 of the current CCSDS 131.0-B-2 version
the term “codeblock length” is used to refer to actual length in octets.
 In this section the term “codeblock length” is used to refer to
a multiplier of the number of codewords that have a size in octets.  That
<u>product</u> yields an actual codeblock length in octets as used elsewhere
in the document.  The use of “codeblock length”, in this context,
is disjoint from how it is used everywhere else in the document.  Please
change “length” to something else like “size” or “multipler”.</b></font><font size=3 face="Times New Roman">
</font><font size=2 color=#800080><b><br>
No problem for me in using size and/or adding a NOTE stating that the final
length in octets is given by...... </b></font><font size=2><b> SLS
would accept the implementation by CCSDS Edior.<br>
[13] ----------------------<br>
D3 Codeblock</b> - Up to <b>Tom</b>: "An R-S" is how the phrase
is spoken, and Publications Manual guidelines for such usage follow spoken
English.    </font><font size=2 color=#800080><b>Accepted by
everybody.</b></font><font size=2><br>
[14] ------------------------</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="sans-serif"><b>SLS also agrees that other two
EDITORIAL issues can be fixed by CCSDS Editor:</b></font>
<br><font size=2 face="sans-serif">a) correct references to old Section
8 that defines the ASM  to be now pointing to Section 9.   </font>
<br><font size=2 face="sans-serif">b) add a forward reference at the first
occurrence of the term CADU to state that the term CADU is defined in Section
9.1.2 </font>
<br><font size=2 face="sans-serif">-------------------------------------------------------------------------------------------------</font>
<br>
<br><PRE>This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.
</PRE>