<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=utf-8">
<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:"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:Aptos;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@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:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:604652952;
mso-list-template-ids:593296410;}
@list l0:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:704913850;
mso-list-template-ids:65708536;}
@list l1:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2
{mso-list-id:762994168;
mso-list-template-ids:1585204788;}
@list l2:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l2:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3
{mso-list-id:1127351980;
mso-list-template-ids:1089123704;}
@list l3:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l3:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4
{mso-list-id:1234389879;
mso-list-template-ids:-1754636874;}
@list l4:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l4:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5
{mso-list-id:1282686428;
mso-list-template-ids:-1157349404;}
@list l5:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l5:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6
{mso-list-id:1387993666;
mso-list-template-ids:459545234;}
@list l6:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l6:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7
{mso-list-id:1432166384;
mso-list-template-ids:-586376688;}
@list l7:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l7:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8
{mso-list-id:1459567887;
mso-list-template-ids:1088197742;}
@list l8:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l8:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9
{mso-list-id:1497914177;
mso-list-template-ids:581042832;}
@list l9:level1
{mso-level-start-at:2;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l9:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10
{mso-list-id:1598708752;
mso-list-template-ids:292575000;}
@list l10:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l10:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif;mso-fareast-language:EN-US">Hi Rick,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif;mso-fareast-language:EN-US">Thanks for your comments. They helped to clarify the scope. Please find some replies below.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Aptos",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" style="margin-left:36.0pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Rick Taylor <rick@tropicalstormsoftware.com>
<br>
<b>Sent:</b> 12 March 2025 18:48<br>
<b>To:</b> Felix Flentge <Felix.Flentge@esa.int>; sburleig.sb@gmail.com; dtn@ietf.org; ''Robert C Durst'' <durst@mitre.org>; Dr. Keith L Scott via SIS-DTN <sis-dtn@mailman.ccsds.org><br>
<b>Subject:</b> RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black">Hi Felix,
<o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black">Thanks for the review, comments inline with [RT].<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
<div>
<div style="margin-left:36.0pt">
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black">
<hr size="1" width="100%" align="center">
</span></div>
</div>
<div id="divRpF57471">
<p class="MsoNormal" style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt">
<b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"> Felix Flentge [Felix.Flentge@esa.int]<br>
<b>Sent:</b> 12 March 2025 14:50<br>
<b>To:</b> Rick Taylor; </span><a href="mailto:sburleig.sb@gmail.com"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">sburleig.sb@gmail.com</span></a><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">;
</span><a href="mailto:dtn@ietf.org"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">dtn@ietf.org</span></a><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">; ''Robert C Durst''; Dr. Keith L Scott via SIS-DTN<br>
<b>Subject:</b> RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">Well,</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"> </span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">Before complaining (</span><span style="font-size:12.0pt;font-family:"Segoe UI Emoji",sans-serif;color:black">😉</span><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">)
I have a few questions/comments (in particular, looking at this from a CCSDS point of view):</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">[RT]. Complaining is good, it shows you care ;)</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"> </span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l10 level1 lfo2">
<![if !supportLists]><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">Regarding the use case of ‘unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by
a unidirectional, unreliable, frame-based link-layer protocol, without requiring IP services’:</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black">
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:108.0pt;text-indent:-18.0pt;mso-list:l10 level2 lfo2">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">This already seems to be addressed by Encapsulation Packet Protocol (</span><a href="https://public.ccsds.org/Pubs/133x1b3e1.pdf" target="_blank"><span style="font-family:"Aptos",sans-serif">https://public.ccsds.org/Pubs/133x1b3e1.pdf</span></a><span style="font-family:"Aptos",sans-serif;color:black">)
and Space Packet Protocol (</span><a href="https://public.ccsds.org/Pubs/133x0b2e2.pdf" target="_blank"><span style="font-family:"Aptos",sans-serif">https://public.ccsds.org/Pubs/133x0b2e2.pdf</span></a><span style="font-family:"Aptos",sans-serif;color:black">);
both work perfectly fine on uni-directional links and are fully compatible with all CCSDS Space Data Link Protocols and Space Data Link Security Protocol. Use of SPP over uni-directional links for payload downlink is common practice for all ESA Earth Observation
missions (though, no BP yet). Reliability is typically addressed closer to the physical layer (coding & modulation) or at a higher layer (CFDP, LTP).</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. BTPU is not intended to be a replacement for EPP or SPP, I foresee it's major use over DVB and Ethernet, but that being said it should run easily
on top of SPP and EPP as required, much like LTP. It's important to remember that an IETF protocol is nothing more than a peer-reviewed protocol, it is not a mandated replacement for any other technology. That being said, I can see a very slim profile of
BTPU over SPP or EPP being something CCSDS could produce, as BTPU does provide some capabilities that EPP/SPP do not.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[FF] OK, understood. I would like to add that there is actually
<a href="https://public.ccsds.org/Pubs/131x3b2e1.pdf">https://public.ccsds.org/Pubs/131x3b2e1.pdf</a></span><span style="font-family:"Aptos",sans-serif"> and
<a href="https://public.ccsds.org/Pubs/131x31o1c1.pdf">https://public.ccsds.org/Pubs/131x31o1c1.pdf</a> for DVB-S2 and DVB-S2X in CCSDS although this is below the SDLP. I don’t know the rationale for that decision. Some useful information may be in
<a href="https://public.ccsds.org/Pubs/130x12g2.pdf">https://public.ccsds.org/Pubs/130x12g2.pdf</a>. BP/Ethernet may be an interesting case. I would see this mainly terrestrial and for maybe telecommunication constellation (which are not so much covered in
CCSDS). </span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:108.0pt;text-indent:-18.0pt;mso-list:l4 level2 lfo4">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">High-Performance Reliability Protocol does also include an unreliable mode for uni-directional links and is fully compatible with CCSDS Packet and Frame layers.</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT] That's good to hear, but I haven't read any HPRP docs, so I can't comment. However, I would love to read them if you have a link?<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[FF] I will need to check with the co-authors. However, I am happy to make it available upon personal request.
</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">So, my questions is why these protocols are not adequate for this use case?</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:72.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">[RT]. I think they are, but BTPU may provide additional capabilities (e.g. multiplexed transfers) that may be desirable, and have applicability outside CCSDS.
Again, BTPU is not a proposed replacement, just another protocol.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif;color:black">[FF] OK, understood. What concerns me slightly is, however, that we define ‘just another protocol’ while we are struggling to get some basic stuff out quickly.
Having more protocols can also create some noise for DTN adoption in space (I don’t see any chances for that in LunaNet) and makes interoperability a bit more trickier. However, if there are good terrestrial or telecom constellation use case, why not.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoListParagraph"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l3 level1 lfo6">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">Regarding ‘...supports data repetition as a mechanism to protect against data loss’:<br>
In space communication we typically try to address reliability at coding and modulation layer (where we can better adapt to the specific link characteristics). Simple repetition does not seem to be a very efficient way. It is sometimes done in spacecraft emergencies
(‘hammering mode’) but for routine operations, I believe we can do better (increased coding or re-transmission protocol).</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT] Completely agree. As I said to Scott B, repetition is not explicitly forbidden in the spec, and therefore is properly documented, and it may have
uses over very basic link-layers or in 'data fountain' use-cases. It's worth remembering that repetition is a per transfer option, so one could repeat segments of one bundle transfer and not others to give finer-grained control. That said, link-layer mechanisms
are probably better and more robust in most cases.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l9 level1 lfo8">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">Regarding ‘... supports the disaggregation of flows of bundles of different priority, preventing head-of-line blocking impacting performance.’<br>
Priorities can be implemented on different levels; for me it makes definitely sense to have it at BP level as this can be universal across convergence layers; for CCSDS Space Data Links, it can be based on Virtual Channels; not sure if there is something required
in addition but if so, we should try to describe the relation between these priorities at different layers.</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT] Agreed. Prioritisation is definitely a BPA task, but CLs ought to support priority when multiplexing transfers, and hence BTPU documents how to do
it. Of course, when a link-layer supports virtual channels, that too can be a perfectly valid mechanism.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo10">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">EPP/SPP provide the functionality to go from variable-size large data structure to fixed length data structures (HPRP/LTP as well). In addition to padding (via insertion
of idle packets), they also allow for aggregation in case there is ‘space left’ in a frame. This is much more efficient then padding. I would assume that the same mechanism (packet service) could be used with BTPU when running over CCSDS Space Data Link Protocols.</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. Yes. When the link-layer supports variable-length "frames" then padding is unnecessary. It's inclusion is for when the link-layer doesn't. The aggregation
capability is implicit in the Message paradigm, a BTPU CLA is expected to pack messages into frames efficiently, and only use padding when it must. When the link-layer does the packing, then no further action is required, apart from avoiding degenerate message
sizes.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l6 level1 lfo12">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">Sequence numbering is provided on CCSDS Space Data Link layer (and I would think also for other frame layer protocols); I am not sure whether an additional segment level
sequence numbering is required.</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. The sequence number is a slightly different concept, as it defines the segment index of a particular transfer, rather than an ordering of messages.
Perhaps I should rename the field to 'Segment Index' to clarify.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[FF] OK, although functionality seems similar (ensure correct reconstruction of the binary block).</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l5 level1 lfo14">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">Cancelling of transfer seems possible for EPP/SPP over CCSDS SDLP by just starting with the next packet (the previous packet is just incomplete but as re-assembly is based
on First Header pointer and not length information this is fine).</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. That's great. In that case, one doesn't need to use the Transfer Cancel - unless one wants to cancel a single Transfer (e.g. Time to live expires)
but continue with other Transfers, but that depends on how one layers BTPU over EPP/SPP over SDLP.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l8 level1 lfo16">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">BPTU-FEC extension: the topic of Forward Error Correction at higher protocol layers comes up from time-to-time; I currently fail to see the advantages compared to FEC we
do at coding & modulation close to the physical layer which seems much more targeted to the specific link. To me, it seems also violating the layering principle a bit (I assume for defining a FEC at a higher level you need to make some assumptions on the lower
layer). </span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. I actually agree with you. FEC to me seems like a property of the link-layer, however I have been asked about it so many times by others that I thought
I would just type up an entirely optional extension to BTPU describing how one could use FEC on a per-transfer basis, if you really wanted it. The major sensible use-case is perhaps in the 'data fountain' use-case, where one wants to add excessive redundancy
for operational reasons.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l2 level1 lfo18">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">What may be missing at CCSDS (TBC) may be the ‘interleaving’ of transfers. However, I am not sure whether this would justify an additional protocol. I don’t see strong use
cases (I think this can typically be addressed by sizing the data blocks to be transmitted to sizes adequate for the available data rates + maybe VC multiplexing).The distinction between emission and transmission is very useful. However, this whole topic
could be quite complex as we would need to consider different on-board architectures (Mass-memory units, on-board busses, buffers in terminals).</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. Head of line blocking is one of those things that really needs to be prevented if one is transferring more than one bundle over a link during a contact.
In the BTPU case, with multiple transfers, multiplexing (and cancelling) seems the right way to go. Having the extra complexity does allow one to do smarter things with resource exhaustion etc, so happy to continue the discussion.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[FF] Yes, definitely worth looking closer into this. We have had similar issues when defining BP QoS Extensions. I think we would benefit from real use
cases and the consideration of typical on-board architectures (where eg frame generation is implemented in terminals while bundles are generated in the data handling system and then send via a bus system). It seems a rather complex topic I am hoping to address
a bit in upcoming study activities.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l7 level1 lfo20">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">Overall, EPP seems to cover at least some of the functionality, it is well specified, fully compatible with the CCSDS stack, baselined for LunaNet and seems less complex
then BTPU. EPP does not require the management of multiple transfers or different message types, so seems to be quite straight-forward to be implemented in hardware at high data rates.</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. Yes. I like EPP/SPP and fully support them. BTPU is not designed to replace either. I can imagine a BTPU service running over a EPP/SPP stack that
is also carrying IP and TT&C in parallel in a very efficient manner.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[FF] Yes. I don’t see any issues with that.</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoListParagraph" style="margin-left:72.0pt;text-indent:-18.0pt;mso-list:l1 level1 lfo22">
<![if !supportLists]><span style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="font-family:"Aptos",sans-serif;color:black">Summary (sorry, I may have ended up complaining): I currently don’t see a clear use case (at CCSDS) for another protocol doing partially what we can already do with EPP
(or SPP for smaller bundles and HPRP in the future if we also want to have a re-transmission option in case we have a bi-directional link). I would propose more of an ‘Adopt – Adapt – Improve’ approach. I am also slightly concerned about the mixing of functions
(segmentation, data repetition, priorisation, maybe FEC) which might be better addressed separately (or are also addressed at other layers).</span><span style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[RT]. And that's fine by me. As I said at the beginning, I see BTPU of interest outside CCSDS, and maybe in the commercial space sector where AOS or TM
exist without the upper layers of the CCSDS stack. I'm just trying to put another tool in the toolbox, rather than propose a replacement for anything.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">[FF] Maybe even more a case where even no AOS/TM exists. Maybe over Cubesat Protocol?</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">Thanks for the thorough review!</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">(Aargh - </span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black">It looks like Outlook has renumbered all the paragraphs -
sorry)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">Cheers,</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black">Rick</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span style="font-family:"Aptos",sans-serif;color:black"><snip></span><span style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify
the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</body>
</html>