<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p>Felix,</p>
<p>I agree. Checksum ID's 0-15 are reserved for CFDP, so that checksum can be added to the blue book without altering the registry. However, it may make sense to allocate two checksum ID's for general (non-CFDP specific) use:
<span>one for private and one for experimental.</span> <br>
</p>
<p><br>
</p>
<p>If we did that, checksums 0-3 would be "real" checksums, 4-12 would be reserved for CFDP, 13 & 14 would be private/experimental, and 15 would NULL.<br>
</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Jeremy<br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Felix.Flentge@esa.int <Felix.Flentge@esa.int><br>
<b>Sent:</b> Wednesday, December 11, 2019 8:10:41 AM<br>
<b>To:</b> chkoo@kari.re.kr; sis-cfdpv1@mailman.ccsds.org; SIS-CFDPV1; Mayer, Jeremy<br>
<b>Subject:</b> Re: [SIS-CFDPV1] revised draft specification</font>
<div> </div>
</div>
<div><span style=" font-size:10pt;font-family:sans-serif">Dear All,</span> <br>
<br>
<span style=" font-size:10pt;font-family:sans-serif">I would support that idea. We could be even more general (also to avoid changing the current draft standard wrt to the MIB) to just have one ID specified as 'Reserved for Private and/or Experimental Use'.</span>
<br>
<br>
<span style=" font-size:10pt;font-family:sans-serif">Regards,</span> <br>
<span style=" font-size:10pt;font-family:sans-serif">Felix</span> <br>
<br>
<br>
<br>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From: </span><span style=" font-size:9pt;font-family:sans-serif"><Jeremy.Mayer@dlr.de></span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To: </span><span style=" font-size:9pt;font-family:sans-serif"><chkoo@kari.re.kr>, <sis-cfdpv1@mailman.ccsds.org></span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date: </span><span style=" font-size:9pt;font-family:sans-serif">11/12/2019 08:01</span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject: </span><span style=" font-size:9pt;font-family:sans-serif">Re: [SIS-CFDPV1] revised draft specification</span>
<br>
<span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Sent by: </span><span style=" font-size:9pt;font-family:sans-serif">"SIS-CFDPV1" <sis-cfdpv1-bounces@mailman.ccsds.org></span>
<br>
<hr noshade="">
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Hi Cheol,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">I can answer your questions about the Checksum registry: First, I'm not sure why the checksum ID's are non-sequential, since I'm not sure what the SANA website is
sorting by, but if you click the "ChecksumID" column header, it should sort correctly.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">I would suggest that, in the scenario which you outlined, the MIB containing the supported checksums for a receiving entity should be updated via TC and/or the desired
checksum should be sent during a filestore request, but that's a more impactful change. I am adverse to a one-to-one allocation of checksum ID's to agencies, since it ultimately negates the purpose of the checksum ID and complicates mission operations and
cross support: a single receiving CFDP entity at a ground station can (and likely will) support multiple missions, some of which may be performed from different agencies, each of which may have their own checksumming capabilities and requirements. If a single
checksum ID is allocated to each agency, the receiving entity will be unable to determine the "real" checksum in use, unless that data is conveyed via some out-of-band mechanism.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Additionally, different files from a single mission may require different checksums, either due to bandwidth constraints, mission phase, and/or avionics capabilities,
meaning that the receiving entity will have to be aware of the mapping between entities, sessions, and checksum configurations. This is further complicated by the rise of file-based operations and advanced FDIR systems: it may be possible for the sending entity
to change checksum modes in the event of a failure, in order in order to reduce power utilization and/or computational complexity.
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">What would be possible is to allocate a single checksum ID to be "MIB defined". If that ID is in use, then it's up to the sender/receiver to determine the checksum
out-of-band, but I think that would require some changes to the blue book.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Thanks,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Calibri">Jeremy </span></p>
<br>
<hr>
<br>
<span style=" font-size:11pt;font-family:Calibri"><b>From:</b> SIS-CFDPV1 <sis-cfdpv1-bounces@mailman.ccsds.org> on behalf of ±¸Ã¶È¸ <chkoo@kari.re.kr><b><br>
Sent:</b> Wednesday, December 11, 2019 1:48:18 AM<b><br>
To:</b> sis-cfdpv1@mailman.ccsds.org<b><br>
Subject:</b> Re: [SIS-CFDPV1] revised draft specification</span><span style=" font-size:12pt;font-family:sans-serif">
</span><br>
<span style=" font-size:12pt;font-family:sans-serif"> </span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Hi, Scott.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">I like your idea. I am currently working on the modification of CFDP software from my side, and I love to perform the supplementary interoperability test when the
updated ION and interoperability test plan are available.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">I don¡¯t see many testing items are required for this supplementary testing. However as I sent it earlier to you there is a tricky issue with regard to handling
condition code of ¡®Unsupported checksum type(1011)¡¯. In order to make that situation, the ¡®Unsupported checksum type¡¯ is generated, happen, a CFDP (sending) entity should be able to generate a checksum field by a checksum algorithm that the other CFDP (receiving)
entity does not support. As there are not much choices in selection of checksum algorithms, it can be tricky because one CFDP entity may have to implement an unnecessary checksum algorithm that is even not consistent with CFDP Checksum Identifiers in SANA
registry (</span><a href="https://sanaregistry.org/r/checksum_identifiers"><span style=" font-size:10pt;color:#0082bf;font-family:sans-serif"><u>https://sanaregistry.org/r/checksum_identifiers</u></span></a><span style=" font-size:10pt;font-family:sans-serif">).</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif"> * short question : why are the number of the checksum ID in the SANA not consistently sequential? E.g., 4,5,</span><span style=" font-size:10pt;color:red;font-family:sans-serif">(6?)</span><span style=" font-size:10pt;font-family:sans-serif">,7,</span><span style=" font-size:10pt;color:red;font-family:sans-serif">(8?)</span><span style=" font-size:10pt;font-family:sans-serif">,9,10,11,12,13,14,</span><span style=" font-size:10pt;color:red;font-family:sans-serif">6,8</span><span style=" font-size:10pt;font-family:sans-serif">,15.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">After thinking about this issue, I like to propose an idea. Why don¡¯t we allocate a Checksum ID to each space agencies, e.g., KARI reserve 5 as a checksum ID for
potential use. Then KARI can freely choose the checksum algorithm for checksum ID 5, e.g., just a copy of modular, CRC32 or whatever or in-house algorithm for sure. When KARI put the 5 at the checksum type field in Metadata PDU, with all the interoperability
testing with space agencies, the ¡®Unsupported checksum type¡¯ condition code should be designated at the FIN PDU from a receiving CFDP entity since all space agencies except KARI doesn¡¯t have any reference for the checksum ID of 5. How do you think?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Cheol</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b> SIS-CFDPV1 <sis-cfdpv1-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Burleigh, Scott C (US 312B) via SIS-CFDPV1<b><br>
Sent:</b> Wednesday, December 11, 2019 1:21 AM<b><br>
To:</b> sis-cfdpv1@mailman.ccsds.org<b><br>
Subject:</b> [SIS-CFDPV1] revised draft specification</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Hi, all. Following some additional discussion of the RID dispositions proposed in the Darmstadt meeting, we now have got a final (I hope) draft specification posted
to CWE at </span><a href="https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.doc?Web=1"><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.doc?Web=1</u></span></a><span style=" font-size:11pt;font-family:Calibri">;
PDF is at </span><a href="https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.pdf"><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.pdf</u></span></a><span style=" font-size:11pt;font-family:Calibri">.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">This draft has gone to the Secretariat for final editing, but the technical stuff won¡¯t be changing unless we discover a problem in interoperability testing.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Speaking of which, I hope to do that (small, supplementary) interoperability test in January. Cheol and Chenyunjun, please take one more look at the markups in the
revised spec to make sure the final tweaks are reflected in your code? I need to modify ION¡¯s CFDP as well and hope to have that done in early January. We¡¯ve discussed a plan for this supplementary testing, and we should try to tie off that discussion and
finalize the plan sometime in the next couple of weeks. (Holidays in the U.S. will complicate this, but it should still be doable.)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">The end is in sight, I swear.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Scott</span></p>
<br>
<tt><span style=" font-size:10pt">_______________________________________________<br>
SIS-CFDPV1 mailing list<br>
SIS-CFDPV1@mailman.ccsds.org<br>
</span></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-cfdpv1"><tt><span style=" font-size:10pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-cfdpv1</span></tt></a><tt><span style=" font-size:10pt"><br>
</span></tt><br>
<br>
</div>
</body>
</html>