<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;}
@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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<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> Jeremy.Mayer@dlr.de <Jeremy.Mayer@dlr.de> <br>
<b>Sent:</b> Monday, May 27, 2019 9:12 AM<br>
<b>To:</b> Burleigh, Scott C (312B) <scott.c.burleigh@jpl.nasa.gov>; sis-cfdpv1@mailman.ccsds.org<br>
<b>Cc:</b> jens.janssen@dlr.de; madalier@antarateknik.com; osvaldo.peinado@dlr.de; thomas.gannett@tgannett.net; Tomaso.deCola@dlr.de<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>
</body>
</html>