<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:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Since current BP implementations are already using code point 1 for BPv6 and BPv7, that one is already spoken for (though BPv7-over-LTP was never formally specified anywhere). The new sequence-of-bundle-byte-strings would come from SANA reserved range.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For the BPv7 blue book this means four changes:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Under Section B2.1.4 “LTP Convergence Layer Adapter” a requirement similar to:<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>When sending bundles according to this specification an LTP CLA shall use Client Service ID for “BPv7 Byte String Sequence” as specified in the SANA LTP Client Service Identifiers registry (reference [XXX]).<o:p></o:p></p><p class=MsoNormal>The BPv6 document in Section B3.1 has similar statements for red and green blocks separately. This specific service name doesn’t really matter, just that it’s short but understandable enough.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Under Section B2.1.4.2 “Length, Value Encoding of Bundles in LTP Blocks” a change similar to:<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Each bundle in an LTP block shall be represented as a CBOR byte string (major type 2) having a definite length of the encoded bundle (including all blocks) in octets.<o:p></o:p></p><p class=MsoNormal>This is the same information encoding and same size as current draft, just with a different major type which is more friendly to CBOR codec libraries (and to diagnostic tools).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In Section D2 “SANA Considerations” a new statement similar to:<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>This document requests that SANA add a record to the LTP Client Service Identifiers registry (reference [XXX]) with value 4 and description “BPv7 Byte String Sequence” referencing this specification.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>A new reference [XXX] to “Licklider Transmission Protocol Client Service Identifiers.” Space Assigned Numbers Authority. <a href="https://sanaregistry.org/r/ltp_serviceid/">https://sanaregistry.org/r/ltp_serviceid/</a> <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Felix Flentge <Felix.Flentge@esa.int> <br><b>Sent:</b> Tuesday, March 12, 2024 5:32 AM<br><b>To:</b> Sipos, Brian J. <Brian.Sipos@jhuapl.edu>; sis-dtn@mailman.ccsds.org<br><b>Subject:</b> [EXT] RE: BPv7/LTP binding issues<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div id=APLWarningText><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 align=left><tr><td width="100%" style='width:100.0%;background:#E0E0E0;padding:0in 0in 0in 0in'><p class=MsoNormal style='mso-element:frame;mso-element-frame-hspace:2.25pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly'><b><span style='color:red'>APL external email warning: </span></b><span style='color:black'>Verify sender <a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a> before clicking links or attachments</span><o:p></o:p></p></td></tr></table><p><span lang=EN-GB style='color:black'> </span><span lang=EN-GB><o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-GB>Hi Brian & All,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Good point: currently we have in IANA:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB><img border=0 width=619 height=141 style='width:6.45in;height:1.4666in' id="Picture_x0020_1" src="cid:image001.png@01DA7616.3DB34D90"></span><span lang=EN-GB><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>And SANA:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><img border=0 width=645 height=95 style='width:6.7166in;height:.9916in' id="Picture_x0020_2" src="cid:image002.png@01DA7616.3DB34D90"></span><span lang=EN-GB><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>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 lang=EN-GB>‘1’ would mean LTP according to 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></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>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></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>And yes, makes sense to have the bundles as definite-length CBOR Byte Strings.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-GB>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Felix<o:p></o:p></span></p></div><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><b>From:</b> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>> <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> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> [Sis-dtn] BPv7/LTP binding issues<o:p></o:p></p></div></div><p class=MsoNormal style='margin-left:.5in'><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:.5in'>All,<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>The CDDL for this would be something like:<o:p></o:p></p><p class=MsoNormal style='margin-left:1.0in'><span 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:1.0in'><span style='font-family:Consolas'>bundle-bytes = bstr .cbor bundle<o:p></o:p></span></p><p class=MsoNormal style='margin-left:1.0in'><span style='font-family:Consolas'>; where “bundle” symbol is from Appendix B of </span>RFC 9171<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>and the diagnostic notation is to enclose items with “<<” and “>>” brackets [5].<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>Thanks for any consideration,<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>Brian S.<o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'>[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></p><p class=MsoNormal style='margin-left:.5in'>[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></p><p class=MsoNormal style='margin-left:.5in'>[3] <a href="https://sanaregistry.org/r/ltp_serviceid/">https://sanaregistry.org/r/ltp_serviceid/</a><o:p></o:p></p><p class=MsoNormal style='margin-left:.5in'>[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></p><p class=MsoNormal style='margin-left:.5in'>[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></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><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></div></body></html>