<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:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:Aptos;}
@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;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:Aptos;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Just two bits from my side. If we intend interleaved frames something like the following, this should be supported by the CCSDS SDLP existing specifications:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><img width="359" height="151" style="width:3.7395in;height:1.5729in" id="Picture_x0020_1" src="cid:image003.png@01DB94D1.8EDDD520"><o:p></o:p></p>
<p class="MsoNormal">Concerning instead the DVB-S2/S2x support in CCSDS, this was done in such a way to keep backward compatibility to the CCSDS protocol stack, i.e. still using the CCSDS transfer frame on top of the DVB-S2 framework. This was the agreement
reached in 2009 from the space agencies involved in the coding&synchronization WG.<o:p></o:p></p>
<p class="MsoNormal"><a id="OWAAM8DD65CD769C74EE885755E734F89CE14" href="mailto:rick@tropicalstormsoftware.com"><span style="font-family:"Calibri",sans-serif;text-decoration:none">@Rick Taylor</span></a>: how do you plan to transport BTPU over DVB, through
GSE or differently?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal"><br>
Tomaso<o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Felix Flentge <Felix.Flentge@esa.int> <br>
<b>Sent:</b> Freitag, 14. März 2025 09:13<br>
<b>To:</b> Rick Taylor <rick@tropicalstormsoftware.com>; 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> [dtn] Re: Bundle Transfer Protocol - Unidirectional<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:Aptos">Hi Rick,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:Aptos"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:Aptos">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 lang="EN-GB" style="font-family:Aptos"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:Aptos">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:Aptos">Felix<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB" style="font-family:Aptos"><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>From:</b> Rick Taylor <<a href="mailto:rick@tropicalstormsoftware.com">rick@tropicalstormsoftware.com</a>>
<br>
<b>Sent:</b> 12 March 2025 18:48<br>
<b>To:</b> Felix Flentge <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>>;
<a href="mailto:sburleig.sb@gmail.com">sburleig.sb@gmail.com</a>; <a href="mailto:dtn@ietf.org">
dtn@ietf.org</a>; ''Robert C Durst'' <<a href="mailto:durst@mitre.org">durst@mitre.org</a>>; Dr. Keith L Scott via SIS-DTN <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br>
<b>Subject:</b> RE: [dtn] Re: Bundle Transfer Protocol - Unidirectional<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">From:</span></b><span lang="EN-GB" 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><span lang="EN-GB"><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><span lang="EN-GB" style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">;
</span><span lang="EN-GB"><a href="mailto:dtn@ietf.org"><span style="font-size:10.0pt;font-family:"Tahoma",sans-serif">dtn@ietf.org</span></a></span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black">Well,</span><span lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black"> </span><span lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black">Before complaining (</span><span lang="EN-GB" style="font-size:12.0pt;font-family:"Segoe UI Emoji",sans-serif;color:black">😉</span><span lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black">)
I have a few questions/comments (in particular, looking at this from a CCSDS point of view):</span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black">[RT]. Complaining is good, it shows you care ;)</span><span lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black"> </span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;color:black">This already seems to be addressed by Encapsulation Packet Protocol (</span><span lang="EN-GB"><a href="https://public.ccsds.org/Pubs/133x1b3e1.pdf" target="_blank"><span style="font-family:Aptos">https://public.ccsds.org/Pubs/133x1b3e1.pdf</span></a></span><span lang="EN-GB" style="font-family:Aptos;color:black">)
and Space Packet Protocol (</span><span lang="EN-GB"><a href="https://public.ccsds.org/Pubs/133x0b2e2.pdf" target="_blank"><span style="font-family:Aptos">https://public.ccsds.org/Pubs/133x0b2e2.pdf</span></a></span><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos"> 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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">a.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black">So, my questions is why these protocols are not adequate for this use case?</span><span lang="EN-GB" 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 lang="EN-GB" style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p> </o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;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 lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-GB" style="font-size:12.0pt;font-family:Aptos;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 lang="EN-GB" style="font-size:12.0pt;font-family:"Times New Roman",serif;color:black"><o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:Aptos;color:black">[FF] OK, although functionality seems similar (ensure correct reconstruction of the binary block).</span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:Aptos;color:black">[FF] Yes. I don’t see any issues with that.</span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="color:black"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="color:black"><o:p></o:p></span></p>
<div>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;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 lang="EN-GB" style="font-family:Aptos;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-GB" style="font-family:Aptos;color:black">[FF] Maybe even more a case where even no AOS/TM exists. Maybe over Cubesat Protocol?</span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;color:black">Thanks for the thorough review!</span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;color:black">(Aargh - </span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;color:black">Cheers,</span><span lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;color:black">Rick</span><span lang="EN-GB" 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 lang="EN-GB" 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 lang="EN-GB" style="font-family:Aptos;color:black"><snip></span><span lang="EN-GB" 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>
<p class="MsoNormal"><span lang="EN-GB">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 (<a href="mailto:dpo@esa.int">dpo@esa.int</a>).
<o:p></o:p></span></p>
</div>
</body>
</html>