<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)">

<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}

o\:* {behavior:url(#default#VML);}

w\:* {behavior:url(#default#VML);}

.shape {behavior:url(#default#VML);}

</style><![endif]--><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:Calibri;

        panose-1:2 15 5 2 2 2 4 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;}

/* 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:#0563C1;

        text-decoration:underline;}

a:visited, span.MsoHyperlinkFollowed

        {mso-style-priority:99;

        color:#954F72;

        text-decoration:underline;}

p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph

        {mso-style-priority:34;

        margin-top:0cm;

        margin-right:0cm;

        margin-bottom:0cm;

        margin-left:40.0pt;

        margin-bottom:.0001pt;

        mso-para-margin-top:0cm;

        mso-para-margin-right:0cm;

        mso-para-margin-bottom:0cm;

        mso-para-margin-left:4.0gd;

        mso-para-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:11.0pt;

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

span.EmailStyle19

        {mso-style-type:personal;

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

        color:windowtext;}

span.EmailStyle20

        {mso-style-type:personal;

        font-family:"맑은 고딕";

        color:windowtext;}

span.EmailStyle21

        {mso-style-type:personal-reply;

        font-family:"맑은 고딕";

        color:windowtext;}

.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="#0563C1" vlink="#954F72">

<div class="WordSection1">

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">Hi, Jeremy.<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:"맑은 고딕""><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:"맑은 고딕"">Appreciate for making good points to think about.<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:"맑은 고딕"">I don</span><span style="font-size:10.0pt;font-family:"맑은 고딕"">’<span lang="EN-US">t follow why do you think as you wrote<o:p></o:p></span></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">   ==> </span>

<span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">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.

<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:"맑은 고딕""><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:"맑은 고딕"">What I am suggesting is to let space agencies have a (or more if necessary) checksum ID in addition to the typical checksum algorithms in SANA

 registry (i.e., modular, Proximity-1, CRC32, CRC32C and NULL). For example KARI CFDP can be configured to support<o:p></o:p></span></p>

<p class="MsoNormal" style="text-indent:20.0pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">0, 3, 15, and 5 (private checksum ID for KARI) while the other agency has 0, 2, 3, 15, 8 (private checksum ID for the other

 agency)<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:"맑은 고딕""><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:"맑은 고딕"">When a sending entity invokes a

</span><span style="font-size:10.0pt;font-family:"맑은 고딕"">‘<span lang="EN-US">filestore request</span>’<span lang="EN-US"> with the Checksum ID 5, the checksum ID (5) will be put in Metadata PDU; thus a receiving entity can identify what is the

</span>“<span lang="EN-US">real</span>”<span lang="EN-US"> checksum in use automatically after parsing the Metadata PDU. There is no need of separate delivery for the checksum type in use. If the receiving entity has the implementation of the checksum algorithm

 (checksum ID 5) by a coordination with KARI, the file can be processed, otherwise it will not be processed and the

</span>“<span lang="EN-US">Unsupported checksum type</span>”<span lang="EN-US"> will be issued, which is the main point of a related testing scenario in the revised CFDP specification.<o:p></o:p></span></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><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:"맑은 고딕"">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:"맑은 고딕""><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:"맑은 고딕""><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:"맑은 고딕""><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"> Jeremy.Mayer@dlr.de <Jeremy.Mayer@dlr.de>

<br>

<b>Sent:</b> Wednesday, December 11, 2019 4:01 PM<br>

<b>To:</b> </span><span style="font-family:굴림">구철회</span><span lang="EN-US"> <chkoo@kari.re.kr>; sis-cfdpv1@mailman.ccsds.org<br>

<b>Subject:</b> Re: revised draft specification<o:p></o:p></span></p>

</div>

</div>

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

<div id="divtagdefaultwrapper">

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">Hi Cheol,<o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">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. <o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">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.

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

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">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. <o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">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.<o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black"><o:p> </o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">Thanks,<o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">Jeremy 

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

</div>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US" style="font-size:12.0pt;font-family:굴림">

<hr size="2" width="98%" align="center">

</span></div>

<div id="divRplyFwdMsg">

<p class="MsoNormal"><b><span lang="EN-US" style="color:black">From:</span></b><span lang="EN-US" style="color:black"> SIS-CFDPV1 <<a href="mailto:sis-cfdpv1-bounces@mailman.ccsds.org">sis-cfdpv1-bounces@mailman.ccsds.org</a>> on behalf of

</span><span style="font-family:굴림;color:black">구철회</span><span lang="EN-US" style="color:black"> <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>><br>

<b>Sent:</b> Wednesday, December 11, 2019 1:48:18 AM<br>

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

<b>Subject:</b> Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US" style="font-size:12.0pt;font-family:굴림">

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

<div>

<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:굴림"> <o:p></o:p></span></p>

</div>

</div>

<div>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">Hi, Scott.<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:"맑은 고딕""><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:"맑은 고딕"">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.<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:"맑은 고딕""><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:"맑은 고딕"">I don</span><span style="font-size:10.0pt;font-family:"맑은 고딕"">’<span lang="EN-US">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

</span>‘<span lang="EN-US">Unsupported checksum type(1011)</span>’<span lang="EN-US">. In order to make that situation, the

</span>‘<span lang="EN-US">Unsupported checksum type</span>’<span lang="EN-US"> 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 (<a href="https://sanaregistry.org/r/checksum_identifiers">https://sanaregistry.org/r/checksum_identifiers</a>).<o:p></o:p></span></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">   * short question : why are the number of the checksum ID in the SANA not consistently sequential? E.g., 4,5,<span style="color:red">(6?)</span>,7,<span style="color:red">(8?)</span>,9,10,11,12,13,14,<span style="color:red">6,8</span>,15.<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:"맑은 고딕""><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:"맑은 고딕"">After thinking about this issue, I like to propose an idea. Why don</span><span style="font-size:10.0pt;font-family:"맑은 고딕"">’<span lang="EN-US">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

</span>‘<span lang="EN-US">Unsupported checksum type</span>’<span lang="EN-US"> condition code should be designated at the FIN PDU from a receiving CFDP entity since all space agencies except KARI doesn</span>’<span lang="EN-US">t have any reference for the

 checksum ID of 5. How do you think?<o:p></o:p></span></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕""><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:"맑은 고딕"">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:"맑은 고딕""><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 <<a href="mailto:sis-cfdpv1-bounces@mailman.ccsds.org">sis-cfdpv1-bounces@mailman.ccsds.org</a>>

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

<b>Sent:</b> Wednesday, December 11, 2019 1:21 AM<br>

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

<b>Subject:</b> [SIS-CFDPV1] revised draft specification<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.  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

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

https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.doc?Web=1</a>; PDF is at

<a href="https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.pdf">

https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.pdf</a>.<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">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.<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">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.)<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">The end is in sight, I swear.<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>

</div>

</body>

</html>