<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body dir="auto">
I also agree that having too many possible choices for possible checksum algorithm is probably not necessary. If we consider the most used ones today plus some possibly new more effective versions (who knows!) in the future, going for 4 bits seems reasonable
 to me.
<div><br>
</div>
<div>Tomaso<br>
<br>
<div id="AppleMailSignature" dir="ltr">Sent from my iPhone</div>
<div dir="ltr"><br>
On 28. May 2019, at 00:56, Burleigh, Scott C (312B) <<a href="mailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<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;}
@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:0in;
        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:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        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:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        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-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
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]-->
<div class="WordSection1">
<p class="MsoNormal"><span 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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Scott<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <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></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi,<o:p></o:p></span></p>
<p class="MsoNormal"><span 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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span 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"><o:p> </o:p></p>
<p class="MsoNormal"><span 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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span 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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Scott<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <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></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hey,<o:p></o:p></span></p>
<p class="MsoNormal"><span 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 style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">From:</span></b><span 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"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Scott<o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</body>
</html>