[CESG] CESG Poll on TM Coding Pink Book: SEA conditions accepted by SLS

[Gian.Paolo.Calzolari at esa.int]

Dear Peter,
        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.

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. 
Therefore RIDs may be issued during Agency Review.

I am confident we can proceed to CMC Poll on this basis after CCSDS 
Editors implements the agreed changes.

I wish you all a nice week end.

Gian Paolo

-------------------------------------------------------------------------------------------
SEA conditions accepted by SLS
[1] 
------------------------------------------------------------------------------------------------- 

Section 2.3.1 -  SLS Proposed change to: 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. 
Section 2.3.1 -  PS Proposed change to: 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 described in 
section 8 and shown explicitly in Figure 8-2. 
No problem with PS further proposal.  
AGREED TO CHANGE TO: (Section 2.3.1) 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 described in 
section 8 and shown explicitly in Figure 8-2. 
[2] -----------
Comment to Figure 2-2: 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 "and for this reason is not 
explicitly shown in Figure 2-2." 
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.? 
No problem with PS further proposal. 
AGREED NOT TO CHANGE Figure 2-2 after accepted change in Section 2.3.1.
[3] ----------
Section 2.3.2 - 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. 
Section 2.3.2 - 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 described in section 8 and shown explicitly in 
Figure 8-2.     
No problem with PS further proposal. 
AGREED TO CHANGE TO: (Section 2.3.2) When LDPC decoding of a stream of 
CADUs  is performed, the receiving end does Code Sync Marker detection and 
codeword derandomization as described in section 8 and shown explicitly in 
Figure 8-2. 
[4] ------------
Comment to Figure 2-3: As for Figure 2-2, it may be worth to complete that 
sentence stating "and for this reason is not explicitly shown in Figure 
2-3." or simply "and it is not shown in Figure 2-3." 
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.? 
No problem with PS further proposal. 
AGREED NOT TO CHANGE Figure 2-3 after accepted change in Section 2.3.2.
[5] ------------------
Section 8.1 - Fine changing to "at sending end".     Accepted by 
everybody. 
[6] ------------------
Section 8.2.1 - Fine changing to "at receiving end".     Accepted by 
everybody. 
[7] ---------------------
Section 8.2.7 and Figure 8-2 - Indeed harmonisation between receiving end 
and receiving side shall be carried out. Tom Gannett proposes a global 
change From 
"receive side" and "receiving side"  
to: "receiving end". 
Accepted by everybody. 
[8] -------------------
9.1.2 - OK typo to be corrected.                 Accepted by everybody. 
[9] ----------------
9.3.3 - Tom Gannett proposes to change from:   ."data that applies LDPC 
coding of a transfer frame" 
To   "data that is LDPC coded as the result of applying LDPC coding to a 
transfer frame" 
+ (similar changes to 9.3.4 and 9.3.5) 
Accepted by everybody. 
[10] -----------
10.2 - 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 and randomization is applied 
according to  8.4 and figure 8-3. 
Accepted by everybody. 
[11] -----------
Section 11.9 - The requirement is needed as long as USLP frames are not 
approved. It may change later. No change for the time being.    Accepted 
by everybody. 
[12] -----------
Table 12-6: "Codeblock length" is used throughout the document.. Tom 
proposes leaving it alone. Peter further comments: 
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 
product 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?. 
No problem for me in using size and/or adding a NOTE stating that the 
final length in octets is given by......  SLS would accept the 
implementation by CCSDS Edior.
[13] ----------------------
D3 Codeblock - Up to Tom: "An R-S" is how the phrase is spoken, and 
Publications Manual guidelines for such usage follow spoken English.    
Accepted by everybody.
[14] ------------------------ 
SLS also agrees that other two EDITORIAL issues can be fixed by CCSDS 
Editor:
a) correct references to old Section 8 that defines the ASM  to be now 
pointing to Section 9. 
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 
-------------------------------------------------------------------------------------------------


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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160708/bd7eff2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 131x0p20_CESG_Approval-SEA.pdf
Type: application/octet-stream
Size: 665329 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160708/bd7eff2e/attachment.obj>