<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=us-ascii">
<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:Consolas;
panose-1:2 11 6 9 2 2 4 3 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:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",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;}
--></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="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi Brian & All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Good point: currently we have in IANA:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><img width="619" height="141" style="width:6.4464in;height:1.4642in" id="Picture_x0020_1" src="cid:image001.png@01DA7466.80992FA0"></span><span style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">And SANA:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><img width="645" height="95" style="width:6.7142in;height:.988in" id="Picture_x0020_2" src="cid:image002.png@01DA7466.80992FA0"></span><span style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">We may be able to argue that ‘1’ is BPv6 as it points to RfC 5050, so maybe it is possible to have ‘4’ for aggregated BPv7 bundles (or 4 for non-aggregated and 5 for aggregated bundles?).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">‘1’ would mean LTP according to
</span>CCSDS 734.2-B-1 and 4 (+5?) would be defined in CCSDS 734.2-B-2 (I think IETF never formally standardised LTPCL, or?).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I probably also need to define to use ‘3’ in the updated CFDP UT Layer Magenta Book (also, to my knowledge, nothing has been formally syandardised before, so it should be fine to have aggregation of CFDP PDU there).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">And yes, makes sense to have the bundles as definite-length CBOR Byte Strings.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Felix<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="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"> SIS-DTN <sis-dtn-bounces@mailman.ccsds.org>
<b>On Behalf Of </b>Sipos, Brian J. via SIS-DTN<br>
<b>Sent:</b> Monday, March 11, 2024 1:56 PM<br>
<b>To:</b> sis-dtn@mailman.ccsds.org<br>
<b>Subject:</b> [Sis-dtn] BPv7/LTP binding issues<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:36.0pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">All,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">I hadn’t looked into the convergence layers section of the draft BPv7 blue book [1] earlier, and understand that these comments are coming late in the draft process.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">The requirements in Section B2.1.4 “LTP Convergence Layer Adapter” currently don’t actually specify which LTP Client Service ID is to be used for this CLA and because this “multiple bundles
within a block” encoding scheme is different than what is defined for Client Service code point 1, I think that a new Client Service code point needs to be allocated for this encoding. It would also be valuable for a decoder to understand whether this encoding
form allows only BPv7 bundles to be present or also v6 (or even a mix of the two). These are all considerations that if left unspecified will lead to interoperability failures.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Separate from the Client Service ID, the notion of a “length prefixed set of bytes” within CBOR is actually how the byte string major type [4] operates and this encoding seems like it would
be better understood by encoders and decoders as a byte string type. In fact, this pattern of CBOR-within-byte-string is common enough that there is both CDDL schema for it as well as CBOR diagnostic notation for it. This second comment is less of an interoperability
issue and more of a way to stick to existing tooling conventions for handling bstr-embedded CBOR.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">The CDDL for this would be something like:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US" style="font-family:Consolas">bp-in-block = (+bundle-bytes) ; encoded as a CBOR sequence<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US" style="font-family:Consolas">bundle-bytes = bstr .cbor bundle<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:72.0pt"><span lang="EN-US" style="font-family:Consolas">; where “bundle” symbol is from Appendix B of
</span><span lang="EN-US">RFC 9171<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">and the diagnostic notation is to enclose items with “<<” and “>>” brackets [5].<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Thanks for any consideration,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">Brian S.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">[1] <a href="https://public.ccsds.org/review/CCSDS%20734.2-P-1.1/734x2p11e1.pdf">
https://public.ccsds.org/review/CCSDS%20734.2-P-1.1/734x2p11e1.pdf</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">[2] <a href="https://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml#client-service-ids">
https://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml#client-service-ids</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">[3] <a href="https://sanaregistry.org/r/ltp_serviceid/">
https://sanaregistry.org/r/ltp_serviceid/</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">[4] <a href="https://www.rfc-editor.org/rfc/rfc8949.html#section-3.1-2.5">
https://www.rfc-editor.org/rfc/rfc8949.html#section-3.1-2.5</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US">[5] <a href="https://www.rfc-editor.org/rfc/rfc8610#appendix-G.3">
https://www.rfc-editor.org/rfc/rfc8610#appendix-G.3</a><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
</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>