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

        font-family:굴림;}

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

        font-family:굴림;}

p.msonormal0, li.msonormal0, div.msonormal0

        {mso-style-name:msonormal;

        margin:0cm;

        margin-bottom:.0001pt;

        font-size:12.0pt;

        font-family:굴림;}

span.EmailStyle19

        {mso-style-type:personal-reply;

        font-family:"맑은 고딕";

        color:windowtext;}

.MsoChpDefault

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

@page WordSection1

        {size:612.0pt 792.0pt;

        margin:3.0cm 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:"맑은 고딕"">Jeremy,<o:p></o:p></span></p>

<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">Given that the filestore request does not contain the desired checksum type (and my suggestion to add it was simply a workaround to

 increasing the MIB complexity),<o:p></o:p></span></p>

<p class="MsoNormal" style="text-indent:6.75pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"맑은 고딕"">==> I like that idea adding the desired checksum type in Put.request() call.<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:"맑은 고딕"">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>

<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" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Jeremy.Mayer@dlr.de <Jeremy.Mayer@dlr.de>

<br>

<b>Sent:</b> Wednesday, December 11, 2019 6:13 PM<br>

<b>To:</b> Felix.Flentge@esa.int<br>

<b>Cc:</b> </span><span style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <chkoo@kari.re.kr>; sis-cfdpv1@mailman.ccsds.org; sis-cfdpv1-bounces@mailman.ccsds.org<br>

<b>Subject:</b> Re: [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>

<div id="divtagdefaultwrapper">

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

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif;color:black">I think that, if we even suggest that users have the choice of private checksums, we have to provide some guidance with regards to the processing of these checksums. Otherwise we'll

 wind up in the scenario which Cheol pointed out where the receiving entity assumes that it can process the private checksum, but the file fails validation and generates a "file checksum" failure, since the checksum is private. In my opinion, that isn't really

 the correct behavior, since a Unsupported Checksum Type fault would be more appropriate.

<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">It doesn't have to be much, "the private checksum MAY be implemented." & "If the private checksum is implemented, the sending and receiving entities must ensure that an unambiguous selection

 of checksum algorithms is ensured for a given file transfer. If this cannot be ensured, an Unsupported Checksum Type fault SHALL be generated". This also covers the interoperability testing: if the sending entity can support the selection of a private checksum

 while the receiving entity can't determine it, then it's compliant with the specification.

<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">Given that the filestore request does not contain the desired checksum type (and my suggestion to add it was simply a workaround to increasing the MIB complexity), the receiving entity

 will not know what checksum is in use until the initial metadata PDU, at which point we have to be able to deterministically process or reject it.<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>

<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"><o:p> </o:p></span></p>

</div>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

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

</span></div>

<div id="divRplyFwdMsg">

<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">

<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a> <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>><br>

<b>Sent:</b> Wednesday, December 11, 2019 9:25:52 AM<br>

<b>To:</b> Mayer, Jeremy<br>

<b>Cc:</b> <a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>; <a href="mailto:sis-cfdpv1@mailman.ccsds.org">

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

sis-cfdpv1-bounces@mailman.ccsds.org</a><br>

<b>Subject:</b> Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US">

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

<div>

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

</div>

</div>

<div>

<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Hmmh,</span><span lang="EN-US">

<br>

<br>

<span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">I wouldn't like to introduce too much change in the draft at the current stage.

</span><span lang="EN-US"><br>

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">In general, I think:</span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">1) We could have checksum ID for private / experimental use but its use should be discouraged.</span><span lang="EN-US">

<br>

<span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">2) Implementations may or may not support private / experimental checksums (or be configurable). This could go to the MIB but does not have to (as for the other checksum ID).

 It's an implementation matter.</span><span lang="EN-US"> <br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">3) If an implementation chooses to support private / experimental checksums, it will try to apply a checksum which may either succeed or fail. Which exact checksum to apply is

 again an implementation matter, could be per source or generic or guessing based on some other information ...</span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">4) If an implementation chooses not to support private / experimental checksums, it will raise the Unsupported Checksum Type fault.</span><span lang="EN-US">

<br>

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">For the interoperability testing, I am not sure how much of this has to be covered. As the private / experimental checksum is, well 'private/experimental', I don't think we have

 to test something for the standard interoperability. Dealing with unsupported checksums seems also more a 'local' entity issue and not so much required for interoperability testing.</span><span lang="EN-US">

<br>

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards,</span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Felix</span><span lang="EN-US">

<br>

<br>

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>></span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>, <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>,

 <<a href="mailto:sis-cfdpv1@mailman.ccsds.org">sis-cfdpv1@mailman.ccsds.org</a>>, <<a href="mailto:sis-cfdpv1-bounces@mailman.ccsds.org">sis-cfdpv1-bounces@mailman.ccsds.org</a>></span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">11/12/2019 08:49</span><span lang="EN-US">

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US">

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

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">

</span></div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>

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

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif">Understood, and to respond to both of your emails at once: I think that the "private/experimental" checksum ID will cover this scenario, without requiring the allocation of the limited range of

 checksum ID's which are supported by CFDP.</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif">To use your example, if the sending entity uses a private checksum algorithm, then they would put checksum ID

<b>private_use</b> (whichever ID that may be) into the metadata PDU. Upon receiving that checksum, the receiving entity

MUST search the MIB in order to determine which checksum is used for that source CFDP entity ID, and process accordingly. If it doesn't find a checksum, then the "Unsupported Checksum Type" error is raised.

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

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif">This would still increase the complexity of the MIB and checksum processing pipeline, but we can outline that the private_use checksum ID MUST search the MIB to determine the actual checksum algorithm,

 and shall fail if  more or less than 1 checksum matches for a given CFDP source entity ID.

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

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

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

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

<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

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

</span></div>

<p class="MsoNormal"><span lang="EN-US"><br>

</span><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">

</span><span style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>><b><br>

Sent:</b> Wednesday, December 11, 2019 8:46:23 AM<b><br>

To:</b> Mayer, Jeremy; <a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>;

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

sis-cfdpv1-bounces@mailman.ccsds.org</a><b><br>

Subject:</b> RE: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US"><br>

</span><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US">

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

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi, Felix.</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">If we choose one ID as 'Reserved for Private and/or Experimental Use, that means a CFDP implementation can support the ID; therefore when the ID is applied to a filestore request,

 a receiving entity (who can handle the ID) will have no problem to process the request. No fault condition can be issued.</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Jeremy’s idea can handle the situation. But a ‘prior coordination between agencies’ should be made before entering a real testing in order to know which one is an implemented checksum

 algorithm (because the sending entity have to process a file delivery request), or a fake algorithm (non-support algorithm). I think that could be not what we want in this context.</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Cheol</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">

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

<b><br>

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

To:</b> <a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>; </span>

<span style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <<a href="mailto:chkoo@kari.re.kr">chkoo@kari.re.kr</a>>;

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

sis-cfdpv1-bounces@mailman.ccsds.org</a><b><br>

Subject:</b> Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

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

<p><span lang="EN-US" style="font-family:"Calibri",sans-serif">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: one for private and one for experimental.  </span><span lang="EN-US"><o:p></o:p></span></p>

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

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

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

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

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

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

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

</span></div>

<p><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">

</span><span lang="EN-US"><a href="mailto:Felix.Flentge@esa.int"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Felix.Flentge@esa.int</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <</span><span lang="EN-US"><a href="mailto:Felix.Flentge@esa.int"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Felix.Flentge@esa.int</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">><b><br>

Sent:</b> Wednesday, December 11, 2019 8:10:41 AM<b><br>

To:</b> </span><span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">chkoo@kari.re.kr</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">;

</span><span lang="EN-US"><a href="mailto:sis-cfdpv1@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-cfdpv1@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">;

 SIS-CFDPV1; Mayer, Jeremy<b><br>

Subject:</b> Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

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

<p><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Dear All,</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

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><span lang="EN-US" style="font-family:"Arial",sans-serif">

<br>

</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Regards,</span><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span>

<span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

Felix</span><span lang="EN-US" style="font-family:"Arial",sans-serif"> <br>

<br>

<br>

<br>

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

From:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><</span><span lang="EN-US"><a href="mailto:Jeremy.Mayer@dlr.de"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">Jeremy.Mayer@dlr.de</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

To:        <span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif"><<span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">chkoo@kari.re.kr</a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>,

 <</span><span lang="EN-US"><a href="mailto:sis-cfdpv1@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-cfdpv1@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Date:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">11/12/2019 08:01</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Subject:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>

Sent by:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"SIS-CFDPV1" <</span><span lang="EN-US"><a href="mailto:sis-cfdpv1-bounces@mailman.ccsds.org"><span style="font-size:9.0pt;font-family:"Arial",sans-serif">sis-cfdpv1-bounces@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US" style="font-family:"Arial",sans-serif">

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

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

<hr size="2" width="100%" noshade="" style="color:#A0A0A0" align="center">

</span></div>

<p style="margin-bottom:180.0pt"><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

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

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

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

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

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

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

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

<p><span lang="EN-US" style="font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">

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

</span></div>

<p><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>

From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> SIS-CFDPV1 <</span><span lang="EN-US"><a href="mailto:sis-cfdpv1-bounces@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-cfdpv1-bounces@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">>

 on behalf of </span><span style="font-size:11.0pt">구철회</span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> <</span><span lang="EN-US"><a href="mailto:chkoo@kari.re.kr"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">chkoo@kari.re.kr</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">><b><br>

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

To:</b> </span><span lang="EN-US"><a href="mailto:sis-cfdpv1@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-cfdpv1@mailman.ccsds.org</span></a></span><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>

Subject:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Re: [SIS-CFDPV1] revised draft specification</span><span lang="EN-US" style="font-family:"Arial",sans-serif">

<br>

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

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi, Scott.</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",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><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",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><span lang="EN-US"><a href="https://sanaregistry.org/r/checksum_identifiers"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#0082BF">https://sanaregistry.org/r/checksum_identifiers</span></a></span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">).</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">   * 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.</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",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><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Cheol</span><span lang="EN-US"><o:p></o:p></span></p>

<p><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"> </span><span lang="EN-US"><o:p></o:p></span></p>

<p><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> SIS-CFDPV1 <</span><span lang="EN-US"><a href="mailto:sis-cfdpv1-bounces@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-cfdpv1-bounces@mailman.ccsds.org</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">>

<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> </span><span lang="EN-US"><a href="mailto:sis-cfdpv1@mailman.ccsds.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">sis-cfdpv1@mailman.ccsds.org</span></a></span><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>

Subject:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> [SIS-CFDPV1] revised draft specification</span><span lang="EN-US"><o:p></o:p></span></p>

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

<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">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><span lang="EN-US"><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:11.0pt;font-family:"Calibri",sans-serif;color:#0082BF">https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.doc?Web=1</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">;

 PDF is at </span><span lang="EN-US"><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:11.0pt;font-family:"Calibri",sans-serif;color:#0082BF">https://cwe.ccsds.org/sis/docs/SIS-CFDPV1/Draft%20Documents/727x0b5%20--%20Specification%20--%20Blue%20Book/727x0p42_working%204.pdf</span></a></span><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">.</span><span lang="EN-US"><o:p></o:p></span></p>

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

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

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

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

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

<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">The end is in sight, I swear.</span><span lang="EN-US"><o:p></o:p></span></p>

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

<p><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Scott</span><span lang="EN-US"><o:p></o:p></span></p>

<p style="margin-bottom:180.0pt"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>

_______________________________________________</span><span lang="EN-US" style="font-family:"Arial",sans-serif"><br>

SIS-CFDPV1 mailing list<u><span style="color:blue"><br>

</span></u></span><span lang="EN-US"><a href="mailto:SIS-CFDPV1@mailman.ccsds.org"><span style="font-family:"Arial",sans-serif">SIS-CFDPV1@mailman.ccsds.org</span></a></span><u><span lang="EN-US" style="font-family:"Arial",sans-serif;color:blue"><br>

</span></u><span lang="EN-US"><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-cfdpv1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-cfdpv1</span></a><o:p></o:p></span></p>

</div>

</div>

</body>

</html>