<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)"><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;}
/* 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:blue;
        text-decoration:underline;}
span.EmailStyle20
        {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:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:747390201;
        mso-list-template-ids:-1327336976;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1
        {mso-list-id:2115704586;
        mso-list-template-ids:532853464;}
@list l1:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level2
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l1:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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 style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>No, the issue is not the block size; that’s clearly defined in the specification.  The issue is being able to determine the lengths of all the individual client data units that are aggregated in the block.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That is easily determined if the client is BP, because each bundle’s size is self-identifying.  But suppose the client is Email?  How does the LTP engine that receives this LTP block figure out where one of the aggregated emails ends and the next one begins?  That method must be defined somewhere, and the receiving engine can use the client ID – once it is registered with SANA – to look up the parsing method.  But that’s beyond the scope of this specification.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>What Felix is suggesting is, more or less, that each client data unit in the block could be preceded by a 32-bit unsigned integer giving the length of that client data unit, regardless of client ID.  This would be a general mechanism, imposing some additional overhead cost, which is NOT included in the LTP spec.  We need not talk about it.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Sanchez Net, Marc (US 332H) <marc.sanchez.net@jpl.nasa.gov> <br><b>Sent:</b> Wednesday, June 21, 2023 12:05 PM<br><b>To:</b> sburleig.sb@gmail.com; 'Keith Scott' <keithlscott@gmail.com>; 'Tomaso de Cola' <Tomaso.deCola@dlr.de><br><b>Cc:</b> sis-dtn@mailman.ccsds.org<br><b>Subject:</b> RE: [EXTERNAL] Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Looking at table C-1, it seems that there are two parameters related to SDA aggregation, size and time. If I understand this correctly, the problem with the current spec only applies when the LTP block is released because the SDA Aggregation timer expires (if the size limit is reached, then no problem, the size of the block is already specified in Table C-1 and thus is a managed parameters known to the receiver). Is that the correct interpretation? If so, I am not sure we can simply say “that the information needed to delimit the aggregated data units in the SDA structure is beyond the scope of the specification” because it is at least partially already in the specification MIB.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Maybe the solution is to add a note in 7.2.3.4.1.3 saying that implementations may find it useful to pad all LTP blocks released due to time limit reached with enough zeros to complete the LTP block size as specified in Table C-1? But does that really solve the problem? How will the rx know when data ends and padding zeroes start…<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p><p class=MsoNormal>Marc Sanchez Net (332H)<o:p></o:p></p><p class=MsoNormal><span style='font-size:10.0pt;color:gray'>Telecommunications Engineer</span><o:p></o:p></p><p class=MsoNormal style='background:white'><span style='font-size:10.0pt;color:gray'>Jet Propulsion Laboratory<o:p></o:p></span></p><p class=MsoNormal style='background:white'><span style='font-size:10.0pt;color:gray'>Cell:</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222'> </span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:black'><a href="mailto:(617)%20953-7977"><span style='color:#0563C1'>(617) 953-7977</span></a></span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0'> </span><span style='font-size:10.0pt;color:gray'>|</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#0070C0'> </span><span style='font-size:10.0pt;color:gray'>Email:</span><span style='font-size:10.0pt;font-family:"Arial",sans-serif;color:#222222'> </span><span style='color:black'><a href="mailto:marc.sanchez.net@jpl.nasa.gov"><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>marc.sanchez.net@jpl.nasa.gov</span></a></span><span style='font-size:9.5pt;font-family:"Arial",sans-serif;color:#222222'><o:p></o:p></span></p><p class=MsoNormal>-----------------------------------------------------------------------------------------------------------------------<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><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>sburleig.sb--- via SIS-DTN<br><b>Sent:</b> Wednesday, June 21, 2023 7:08 AM<br><b>To:</b> 'Keith Scott' <<a href="mailto:keithlscott@gmail.com">keithlscott@gmail.com</a>>; 'Tomaso de Cola' <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br><b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> [EXTERNAL] Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Right, I think it’s not that the specification is not interoperable, only that the nature of the client data units – including the information needed to delimit the aggregated data units in the SDA structure – is identified by the client ID; that registration is beyond the scope of the specification.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Scott<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><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>Keith Scott via SIS-DTN<br><b>Sent:</b> Wednesday, June 21, 2023 2:36 AM<br><b>To:</b> Tomaso de Cola <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>><br><b>Cc:</b> <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a><br><b>Subject:</b> Re: [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Mmmm.... will try to find the right words. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>  -keith<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Jun 21, 2023, 10:48 AM <<a href="mailto:Tomaso.deCola@dlr.de">Tomaso.deCola@dlr.de</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Keith,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thank you for the summarized discussion on LTP-corrigendum. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Just one consideration about SDA aggregation (point 7 in the list). The description seems to point about the fact that the current specification of the mechanism does not allow interoperability because of the lack of information of the client data unit, which is I think agreed and well understood. I’d however try to find a “smarter” way to say this, since having a specification which has a non-interoperable feature will not be accepted by CESG and this will cause endless iterations and discussions there before getting the green light.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Regards,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Tomaso<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=DE>Von:</span></b><span lang=DE> SIS-DTN <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org" target="_blank">sis-dtn-bounces@mailman.ccsds.org</a>> <b>Im Auftrag von </b>Keith Scott via SIS-DTN<br><b>Gesendet:</b> Dienstag, 20. Juni 2023 18:35<br><b>An:</b> <a href="mailto:sis-dtn@mailman.ccsds.org" target="_blank">sis-dtn@mailman.ccsds.org</a><br><b>Betreff:</b> [Sis-dtn] Updates on LTPv2 Corrigendum and BPv7 RID database</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>LTP Corrigendum (from the telecon last Thursday):<o:p></o:p></p></div><div><ul type=disc><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3'>Discussed the latest JPL collection of issues here (<a href="https://urldefense.us/v3/__https:/cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc=*7bA52D5D6D-7A66-4CCD-AB61-B215AA2B8C36*7d&file=Draft*20LTP*20corrigendum*20-*20JPL*20edits*20(1).docx&action=default__;JSUlJSUlJSU!!PvBDto6Hs4WbVuu7!LCeuTfHRA-LEWR-KvEDLe0i6i_hNmJSv6s71tkiKsE8GF9G2WuONw5VgyJ3VhoHWAzOx4uoYfTZbeHQbcqsxLE9Ue77kmlg$" target="_blank">https://cwe.ccsds.org/sis/_layouts/15/WopiFrame.aspx?sourcedoc={A52D5D6D-7A66-4CCD-AB61-B215AA2B8C36}&file=Draft%20LTP%20corrigendum%20-%20JPL%20edits%20(1).docx&action=default</a>)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3'>We definitely want a CORRIGENDUM (non-normative, no changes to the protocol) NOT a set of Pink sheets or a Pink Book (which would/could be normative and would require agency review).  So, all proposed text should be in the form of non-normative suggestions to implementers.<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3'>We discussed putting all of the proposed changes into a single location or spreading them throughout the document.  The consensus was that it would be better for implementers to put the suggestions proximate to the places in the document that discuss the protocol mechanisms (i.e. mixed throughout).  Should ask Tom what he thinks of this...<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3'>Blue text in the document reflects the WG consensus on the telecon; we agreed that folks would propose final "copy-ready" text in green together with the location where that text should go.<o:p></o:p></li></ul></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Added the CNES RIDs to the spreadsheet.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>    --keith<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div></blockquote></div></div></body></html>