<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=ks_c_5601-1987">

<meta name="Generator" content="Microsoft Word 15 (filtered medium)">

<style><!--

/* Font Definitions */

@font-face

        {font-family:굴림;

        panose-1:2 11 6 0 0 1 1 1 1 1;}

@font-face

        {font-family:"Cambria Math";

        panose-1:2 4 5 3 5 4 6 3 2 4;}

@font-face

        {font-family:"맑은 고딕";

        panose-1:2 11 5 3 2 0 0 2 0 4;}

@font-face

        {font-family:"\@맑은 고딕";}

@font-face

        {font-family:"\@굴림";

        panose-1:2 11 6 0 0 1 1 1 1 1;}

@font-face

        {font-family:Calibri;

        panose-1:2 15 5 2 2 2 4 3 2 4;}

@font-face

        {font-family:Tahoma;

        panose-1:2 11 6 4 3 5 4 4 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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph

        {mso-style-priority:34;

        margin-top:0cm;

        margin-right:0cm;

        margin-bottom:0cm;

        margin-left:36.0pt;

        margin-bottom:.0001pt;

        font-size:11.0pt;

        font-family:"Calibri",sans-serif;}

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:12.0pt;

        font-family:"Times New Roman",serif;}

span.EmailStyle19

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:windowtext;}

span.EmailStyle20

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle21

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle22

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle23

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle24

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle25

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle26

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle27

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle28

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle29

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle30

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle31

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle32

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle33

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:windowtext;}

span.EmailStyle34

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle35

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:windowtext;}

span.EmailStyle36

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle37

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle38

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle39

        {mso-style-type:personal;

        font-family:"Calibri",sans-serif;

        color:#1F497D;}

span.EmailStyle40

        {mso-style-type:personal-reply;

        font-family:"맑은 고딕";

        color:#1F497D;}

.MsoChpDefault

        {mso-style-type:export-only;}

@page WordSection1

        {size:612.0pt 792.0pt;

        margin:72.0pt 72.0pt 72.0pt 72.0pt;}

div.WordSection1

        {page:WordSection1;}

--></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="KO" link="blue" vlink="purple">

<div class="WordSection1">

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕";color:#1F497D">I think for pursuing interoperability selectable checksum types shall be restricted two or three algorithms, which are not trivial

 work for implementers already.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕";color:#1F497D">In my opinion even if plenty choices of checksum algorithms exist in the specification document, the simplest or fastest algorithm

 among them will survive in general. So modular checksum (00), another checksum #1 (01), another checksum #2 (10), and no checksum (11) could answer all the requirements.<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕";color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕";color:#1F497D">Cheol<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕";color:#1F497D"><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"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SIS-CFDPV1 <sis-cfdpv1-bounces@mailman.ccsds.org>

<b>On Behalf Of </b>Burleigh, Scott C (312B) via SIS-CFDPV1<br>

<b>Sent:</b> Tuesday, May 28, 2019 1:56 AM<br>

<b>To:</b> Jeremy.Mayer@dlr.de; sis-cfdpv1@mailman.ccsds.org<br>

<b>Cc:</b> madalier@antarateknik.com; thomas.gannett@tgannett.net; Tomaso.deCola@dlr.de; jens.janssen@dlr.de; osvaldo.peinado@dlr.de<br>

<b>Subject:</b> Re: [SIS-CFDPV1] updated CFDP Revisions draft<o:p></o:p></span></p>

</div>

</div>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">But wouldn’t it be a viable alternative simply to say in the registry definition that the checksum ID is a 6-bit integer?  Or, per Cheol’s suggestion, only a 3-bit integer?  I am actually not a fan

 of restricting this value so much, but a 4-bit integer would give us 14 options for 32-bit checksum algorithms in addition to “modular checksum” and “no checksum”, which might be enough.  A 6-bit integer gives us a total of 64 options, which I strongly suspect

 would be plenty.<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Scott<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><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"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> <a href="mailto:Jeremy.Mayer@dlr.de">

Jeremy.Mayer@dlr.de</a> <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>

<br>

<b>Sent:</b> Monday, May 27, 2019 9:12 AM<br>

<b>To:</b> Burleigh, Scott C (312B) <<a href="mailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov</a>>;

<a href="mailto:sis-cfdpv1@mailman.ccsds.org">sis-cfdpv1@mailman.ccsds.org</a><br>

<b>Cc:</b> <a href="mailto:jens.janssen@dlr.de">jens.janssen@dlr.de</a>; <a href="mailto:madalier@antarateknik.com">

madalier@antarateknik.com</a>; <a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a>;

<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>; <a href="mailto:Tomaso.deCola@dlr.de">

Tomaso.deCola@dlr.de</a><br>

<b>Subject:</b> [EXTERNAL] RE: updated CFDP Revisions draft<o:p></o:p></span></p>

</div>

</div>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Hi,<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">If we are now normatively pointing towards a new registry as the source of checksum ID’s, then we must ensure that all 1-byte checksum ID’s could fit. In the worst case, I would propose that you

 add a 1-bit value (“extended checksum used”) and a 5-bit “base checksum” value. If a checksum is used whose ID is >0x1F (11111b), than you set the extended checksum used bit, nullify the base checksum, and rely upon a “checksum ID” TLV.

<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Thanks,<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Jeremy<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<div>

<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">

<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> Burleigh, Scott C (312B) [<a href="mailto:scott.c.burleigh@jpl.nasa.gov">mailto:scott.c.burleigh@jpl.nasa.gov</a>]

<br>

<b>Sent:</b> Montag, 27. Mai 2019 18:06<br>

<b>To:</b> Mayer, Jeremy; <a href="mailto:sis-cfdpv1@mailman.ccsds.org">sis-cfdpv1@mailman.ccsds.org</a><br>

<b>Cc:</b> Janssen, Jens; <a href="mailto:madalier@antarateknik.com">madalier@antarateknik.com</a>; Peinado, Osvaldo Luis;

<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>; Cola, Tomaso de<br>

<b>Subject:</b> RE: updated CFDP Revisions draft<o:p></o:p></span></p>

</div>

</div>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">A highly salient point, Jeremy.  When I got down to revising the text of the specification I realized that there was a decision to make with regard to the Metadata PDU: the new checksum ID field

 could be added at the end, after all the TLVs, or a slightly truncated checksum ID field could be plugged into the unused bits of the first octet (as was done with the new “closure requested” flag).  I liked option B because it looked easier to parse, but

 it does mess up the registry.<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">In addition, Cheol has suggested that even 6 bits is too long; he would prefer an even shorter checksum ID field that would accommodate far fewer checksum selection options.<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">I’d like to come to a consensus on this question within the WG if possible.  Anybody else have an opinion here?<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Scott<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><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"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> <a href="mailto:Jeremy.Mayer@dlr.de">

Jeremy.Mayer@dlr.de</a> <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>

<br>

<b>Sent:</b> Sunday, May 26, 2019 10:37 PM<br>

<b>To:</b> Burleigh, Scott C (312B) <<a href="mailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov</a>>;

<a href="mailto:sis-cfdpv1@mailman.ccsds.org">sis-cfdpv1@mailman.ccsds.org</a><br>

<b>Cc:</b> <a href="mailto:jens.janssen@dlr.de">jens.janssen@dlr.de</a>; <a href="mailto:madalier@antarateknik.com">

madalier@antarateknik.com</a>; <a href="mailto:osvaldo.peinado@dlr.de">osvaldo.peinado@dlr.de</a>;

<a href="mailto:thomas.gannett@tgannett.net">thomas.gannett@tgannett.net</a>; <a href="mailto:Tomaso.deCola@dlr.de">

Tomaso.deCola@dlr.de</a><br>

<b>Subject:</b> [EXTERNAL] RE: updated CFDP Revisions draft<o:p></o:p></span></p>

</div>

</div>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Hey,<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Everything looks fine from my side, except for one not-so-minor issue: The checksum type ID field is 6 bits long, but has been outlined in the proposed registry as an 1-byte value, and we have (tentatively)

 reserved 0xFF as the NULL checksum. Therefore, the metadata PDU cannot unambiguously define data which is using the NULL checksum.

<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Thanks,<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US" style="color:#1F497D">Jeremy<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<div>

<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">

<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma",sans-serif"> Burleigh, Scott C (312B) [<a href="mailto:scott.c.burleigh@jpl.nasa.gov">mailto:scott.c.burleigh@jpl.nasa.gov</a>]

<br>

<b>Sent:</b> Freitag, 24. Mai 2019 22:17<br>

<b>To:</b> <a href="mailto:sis-cfdpv1@mailman.ccsds.org">sis-cfdpv1@mailman.ccsds.org</a><br>

<b>Cc:</b> Janssen, Jens; <a href="mailto:madalier@antarateknik.com">madalier@antarateknik.com</a>; Mayer, Jeremy; Peinado, Osvaldo Luis; Thomas Gannett; Cola, Tomaso de<br>

<b>Subject:</b> updated CFDP Revisions draft<o:p></o:p></span></p>

</div>

</div>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US">Hi, all.  I have made all the changes to the revised CFDP Blue Book that I think are needed in order to make the file checksum algorithm selectable by reference to the new SANA checksum algorithm registry.  The updated

 document is now in CWE at <a href="https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%202.doc?Web=1">

https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%202.doc?Web=1</a>.  Please take a look at it when you have a moment; I’d like to send a final draft to Tom and ask for a supplementary

 Agency review soon, maybe as early as next month.<o:p></o:p></span></p>

<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>

<p class="MsoNormal"><span lang="EN-US">Scott<o:p></o:p></span></p>

</div>

</body>

</html>