<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)">
<style><!--
/* Font Definitions */
@font-face
{font-family:¹ÙÅÁ;
panose-1:2 3 6 0 0 1 1 1 1 1;}
@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;}
@font-face
{font-family:"\@¹ÙÅÁ";
panose-1:2 3 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;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:±¼¸²;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"¸¼Àº °íµñ";
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-compose;
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:"¸¼Àº °íµñ"">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:"¸¼Àº °íµñ"">Yes, that note somewhere in the draft doc would be helpful!!<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 have another questions. Please find below questions and comments.<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:"¸¼Àº °íµñ"">1. Speaking of handling serial number, will the following practices from RFC-5326 be considered in the LTPv2 draft?<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:"¸¼Àº °íµñ"">From ¡°Checkpoint serial number (SDNV)¡± part in 3.2.1. Data Segment (DS) of RFC-5326<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:"¸¼Àº °íµñ"">1) Any subsequent checkpoints issued by the sender MUST have the serial number value found by incrementing the prior checkpoint serial number
by 1.<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:"¸¼Àº °íµñ"">2) The checkpoint serial number MUST NOT be zero.<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>
<p class="MsoNormal" style="word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"¸¼Àº °íµñ"">2. How new LTPv2 will treat if it encounters below situations?<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:"¸¼Àº °íµñ"">* Acronym and Abbreviations<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:"¸¼Àº °íµñ"">DS : Data Segments<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:"¸¼Àº °íµñ"">DAR : Data Acknowledgement Request<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:"¸¼Àº °íµñ"">MA : Metadata Acknowledgement<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:"¸¼Àº °íµñ"">DA : Data Acknowledgement<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:"¸¼Àº °íµñ"">1) A sending engine sends DS to a receiving engine. After the sending engine transmits final data segments, it sends an DAR.<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:"¸¼Àº °íµñ"">Then the receiving engine replies to that request with an MA and an DA. Let¡¯s consider that the MA is lost during transaction but the DA are
successfully transmitted. Then the sending engine does not receive the MA but DOES receive the DA.<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:"¸¼Àº °íµñ""> *<b>Question</b>* How the sending engine will treat this? Retransmit the same DAR?<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:"¸¼Àº °íµñ"">The sending engine CAN¡¯T infer explicitly (*NOTE* can be implicitly possible) that just received DA are related to the DAR because the DA field
has no information about the serial number accompanied with the DAR, the MA DOES have that information but it is lost during transaction. If the sending engine retransmits the DAR again, the receiving engine has to retransmit MA and all DA again, possibly
causing retransmission of DS by the sending engine.<o:p></o:p></span></p>
<p class="MsoNormal" style="text-indent:7.2pt;word-break:break-hangul"><span lang="EN-US" style="font-size:10.0pt;font-family:"¸¼Àº °íµñ"">*<b>TO PREVENT THIS</b>* I think, an MA and DA shall be mandated to be included together within a LTP block. Alternatively,
the DA can have an additional field indicating the relevant DAR¡¯s serial number as a reference just in case.<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:"¸¼Àº °íµñ"">2) DA on a receiving engine can be triggered by an DAR from a sending engine(Type 0x00) or implementation-specific heuristics (Type 0x01). In
some circumstances, multiple occurrences of DS and DAR followed by DS can be possible. Or a malicious attacker can send an DA to a sending engine. A sending engine needs a way how to deal with it appropriately.<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:"¸¼Àº °íµñ"">Best,<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" 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> Tuesday, May 16, 2023 5:37 PM<br>
<b>To:</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>; Felix.Flentge@esa.int<br>
<b>Cc:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> RE: [Sis-dtn] LTPv2 Draft Blue Book for Review<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-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Hi Cheol,<br>
The length of any field within the headers are fixed per-session, so if you chose a (for example) 4-byte serial number, you¡¯re stuck with it until the transmission has completed. That¡¯s why we can always infer the SN length from the extension header. Since
we only support session-level interleaving (e.g. extensions/metadata cannot span across multiple session numbers), we can simplify the length finding logic.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">I¡¯ll add a section describing the ¡°rules¡± for lengths, since presently it¡¯s sort of non-normative and in an annex.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><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">
</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>>
<br>
<b>Sent:</b> Tuesday, May 16, 2023 10:14 AM<br>
<b>To:</b> Mayer, Jeremy <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>;
<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>; <a href="mailto:ccorsten@gmv.com">
ccorsten@gmv.com</a><br>
<b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br>
<b>Subject:</b> RE: [Sis-dtn] LTPv2 Draft Blue Book for Review<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p><span lang="EN-US" style="font-size:10.0pt">Hi, Jeremy & Felix.<br>
<br>
I have a question about the Serial number in the Extensions header.<br>
<br>
During configuration of an extension field, we refer below section for identifying appropriate serial number.<br>
4.2.8.4.3.6 Extension Serial Number<br>
4.2.8.4.3.6.1 The second field within a single entry must be the extension serial number<br>
4.2.8.4.3.6.2 The length of this field (in octets) must be represented by the value of the serial number length field within the extension header.<br>
4.2.8.4.3.6.3 The extension serial number field must be set to the value of a previously-received serial number.<br>
<br>
By assuming followings:<br>
1) the serial number will be randomly generated in [1, 2^64-1].<br>
2) and the length of the serial number is variable and in range 1 ~ 8 bytes.<br>
<br>
Now, questions<br>
1) Can the length of extension's serial number each LTPv2 segment be different? (It seems current draft says it Yes)<br>
If above question's answer is Yes, members of the Extension Serial Number(s) in the metadata Acknowledgement Extension can be different in their size. If this is correct assumption, then a consideration for inferring the length of each Serial Number(s) is needed.
See Section 4.2.8.4.3.6.<br>
<br>
For short, "the value of the serial number length field within the extension header" can't be useful for understanding the multiple "Extension Serial Number" field in every elements of the Metadata Acknowledgement Extension.<br>
<br>
<br>
Best,<br>
Cheol<br>
<br>
<br>
-----Original Message-----<br>
From: </span><span style="font-size:10.0pt">±¸Ã¶È¸<span lang="EN-US"><br>
Sent: Monday, May 15, 2023 4:10 PM<br>
To: 'Jeremy.Mayer@dlr.de' <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>>; 'Felix.Flentge@esa.int' <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>; 'ccorsten@gmv.com' <<a href="mailto:ccorsten@gmv.com">ccorsten@gmv.com</a>><br>
Cc: 'sis-dtn@mailman.ccsds.org' <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
Subject: [Sis-dtn] LTPv2 Draft Blue Book for Review<br>
<br>
Hi, Jeremy & Felix.<br>
<br>
I am reading the draft of LTPv2.<br>
I have found some typos and wrong numbering. Please find the attached document commented by me until Section 5.<br>
And I put some thoughts from me.<br>
Hope this be useful for finalizing the draft document.<br>
<br>
Best,<br>
Cheol<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 9 May 2023 21:47:52 +0000<br>
From: <<a href="mailto:Jeremy.Mayer@dlr.de">Jeremy.Mayer@dlr.de</a>><br>
To: <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
Cc: <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>, <<a href="mailto:ccorsten@gmv.com">ccorsten@gmv.com</a>><br>
Subject: [Sis-dtn] LTPv2 Draft Blue Book for Review<br>
Message-ID: <<a href="mailto:ce39808e8d454bc6a1b9492a9c3601d6@dlr.de">ce39808e8d454bc6a1b9492a9c3601d6@dlr.de</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi everyone,<br>
In order to provide a baseline for tomorrows discussion of the proposed LTPv2 protocol, I've attached the draft blue book for the standard. After showcasing the proposed approach and rational, we're intending to go through the document, focusing on the underlying
protocol.<br>
<br>
Thanks,<br>
Jeremy & Felix<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=49654323-16fe292b-496032ad-ac1f6bdccbcc-9f3a4573ad06235c&q=1&e=e8df1ab1-ca9a-403e-8725-23603284ec27&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.htm">https://protect2.fireeye.com/v1/url?k=d594e974-8a0f837c-d59198fa-ac1f6bdccbcc-1bc9b51193935a08&q=1&e=240c812c-b72b-4c10-a8ce-bbd260da108e&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.htm</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: LTPv2 Blue Book Draft 28.04.2023_for CCSDS Review.doc<br>
Type: application/msword<br>
Size: 446976 bytes<br>
Desc: LTPv2 Blue Book Draft 28.04.2023_for CCSDS Review.doc<br>
URL: <<a href="https://protect2.fireeye.com/v1/url?k=e73cb4fe-b8a7def6-e739c570-ac1f6bdccbcc-ae0de84bd02f3bcf&q=1&e=e8df1ab1-ca9a-403e-8725-23603284ec27&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.doc">https://protect2.fireeye.com/v1/url?k=dfc4f39a-805f9992-dfc18214-ac1f6bdccbcc-1eea1efeeb0ae6a7&q=1&e=240c812c-b72b-4c10-a8ce-bbd260da108e&u=http%3A%2F%2Fmailman.ccsds.org%2Fpipermail%2Fsis-dtn%2Fattachments%2F20230509%2Fa4acfc78%2Fattachment.doc</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
SIS-DTN mailing list<br>
<a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a><br>
<a href="https://protect2.fireeye.com/v1/url?k=62de3d02-3d45570a-62db4c8c-ac1f6bdccbcc-cd7a61e7db81d855&q=1&e=e8df1ab1-ca9a-403e-8725-23603284ec27&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn">https://protect2.fireeye.com/v1/url?k=ba7eab5f-e5e5c157-ba7bdad1-ac1f6bdccbcc-e5e5ee1302fcc2a6&q=1&e=240c812c-b72b-4c10-a8ce-bbd260da108e&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn</a><br>
<br>
<br>
------------------------------<br>
<br>
End of SIS-DTN Digest, Vol 143, Issue 4<br>
***************************************</span></span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</body>
</html>