<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
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
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
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:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:354037831;
mso-list-type:hybrid;
mso-list-template-ids:-662000542 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
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><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>The IETF language should be “MUST” in this instance (and not must). <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>The encoding (and perhaps at-waypoint transcoding) needs to be deterministic. I think that option 3 below has to be avoided, but opening up block fields to a variety of encodings might not be the best way to prevent that.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Consider the case where one BPA adds a block with a fixed 64-bit block type. And then, another BPA (at a waypoint) adds a new block to the bundle (which is allowed) but does so with a fixed-width 32-bit block type, and yet another BPA adds another block to the bundle with an 8-bit block type. At a bundle destination, some logic would still need to understand the widths of these fields. For example, if the bundle destination in this case were to be firmware that expects a fixed 32-bit field for block type, the aforementioned bundle would break that implementation. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I think we should avoid that and have individual BPAs condition data going into and out-of FPGAs. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>-Ed<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><p class=MsoNormal><span style='font-size:10.0pt;color:#1F497D'>Edward J. Birrane, III, Ph.D. (he/him/his)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#1F497D'>Chief Engineer, Space Constellation Networking<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#1F497D'>Space Exploration Sector<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#1F497D'>Johns Hopkins Applied Physics Laboratory<br>(W) 443-778-7423 / (C) 443-690-8272</span><span style='color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='color:#1F497D'><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><b>From:</b> Dr. Keith L Scott <kscott@mitre.org> <br><b>Sent:</b> Thursday, December 2, 2021 10:21 AM<br><b>To:</b> Felix.Flentge@esa.int; Birrane, Edward J. <Edward.Birrane@jhuapl.edu><br><b>Cc:</b> Scott Burleigh <scott.c.burleigh@jpl.nasa.gov>; sis-dtn@mailman.ccsds.org<br><b>Subject:</b> Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I *<b>think</b>* the issue here is going to be:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>IF somebody wants to implement BPv7 in hardware, they might want ‘known-sized’ fields (akin to the field set selector we’re working towards in LTP – an identifier that a receiver can use as a key to look up the field lengths in the rest of a bundle). If somebody DOES want that as a way to facilitate high-speed hardware implementations, and if the IETF text becomes a MUST (not a must) then we’ll have your option3 below.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> --keith<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-bottom:12.0pt'><b><span style='font-size:12.0pt;color:black'>From: </span></b><span style='font-size:12.0pt;color:black'><a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a> <<a href="mailto:Felix.Flentge@esa.int">Felix.Flentge@esa.int</a>><br><b>Date: </b>Thursday, December 2, 2021 at 1:59 AM<br><b>To: </b>Birrane, Edward J. <<a href="mailto:Edward.Birrane@jhuapl.edu">Edward.Birrane@jhuapl.edu</a>><br><b>Cc: </b>Dr. Keith L Scott <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, Scott Burleigh <<a href="mailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov</a>>, <a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a> <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>><br><b>Subject: </b>Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Well,</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>I think the point here is whether it is 'must' or 'MUST'.</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Is there any intention to keep some flexibility for IETF DTN here or not?</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>It's an important point for (efficient) on-board implementations. CCSDS should be very clear on CBOR serialisation. So, I see four options</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>1) IETF has a MUST, CCSDS confirms this MUST</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>2) IETF has a 'must'--> CCSDS makes is a MUST</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>3) IETF has a MUST --> CCSDS decides to implement a different serialisation (to guarantee fixed block sizes independent from actual values)</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>4) IETF has a 'must'--> CCSDS decides to implement a different serialisation</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Clearly, 3) needs to avoided and I would hope that we do not need to go to 4) ( the initial feedback is that deterministic CBOR is ok for on-board implementations, TBC).</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Ideally, we would have 1) but in order to avoid 3) we might want to stay with 1)</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>On the indefinite-length exception, I'm not sure. I think the requirement for deterministic CBOR is on the blocks/fields and not the entire bundle (which is currently the only indefinite length item).</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>So, we might allow indefinite-length also in blocks (which may lead to slightly more efficient encoding but might make decoding slightly more difficult). In this case, we might want to extend the deterministic CBOR requirement (with the exception) to the whole bundle.</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Or we might not allow in-definite length for blocks/fields and state explicitly that this does not apply to the full bundle.</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>(I do hope, I have not been to confusing. It's still quite early for me.)</span> <br><br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Regards,</span> <br><span style='font-size:10.0pt;font-family:"Arial",sans-serif'>Felix</span> <br><br><br><br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>From: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Birrane, Edward J." <<a href="mailto:Edward.Birrane@jhuapl.edu">Edward.Birrane@jhuapl.edu</a>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>To: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"Dr. Keith L Scott" <<a href="mailto:kscott@mitre.org">kscott@mitre.org</a>>, "Scott Burleigh" <<a href="mailto:scott.c.burleigh@jpl.nasa.gov">scott.c.burleigh@jpl.nasa.gov</a>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Cc: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>" <<a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a>></span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Date: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>01/12/2021 21:30</span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Subject: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>Re: [Sis-dtn] [EXT] Canonical CBOR in BPv7 a MUST for block field encoding?</span> <br><span style='font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F'>Sent by: </span><span style='font-size:9.0pt;font-family:"Arial",sans-serif'>"SIS-DTN" <<a href="mailto:sis-dtn-bounces@mailman.ccsds.org">sis-dtn-bounces@mailman.ccsds.org</a>></span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="97%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal><br><br><br><span style='font-size:12.0pt'>I believe this is changed to deterministic CBOR with the exception the indefinite length items are not prohibited. </span><br><br><span style='font-size:12.0pt'>Sent with BlackBerry Work<br>(</span><a href="www.blackberry.com"><span style='font-size:12.0pt'>www.blackberry.com</span></a><span style='font-size:12.0pt'>)</span> <br><span style='font-size:12.0pt'><br></span><br><b>From: </b>Dr. Keith L Scott <<a href="mailto:kscott@mitre.org"><span style='color:#0082BF'>kscott@mitre.org</span></a>> <br><b>Date: </b>Wednesday, Dec 01, 2021, 12:01 PM <br><b>To: </b>Scott Burleigh <<a href="mailto:scott.c.burleigh@jpl.nasa.gov"><span style='color:#0082BF'>scott.c.burleigh@jpl.nasa.gov</span></a>>, Birrane, Edward J. <<a href="mailto:Edward.Birrane@jhuapl.edu"><span style='color:#0082BF'>Edward.Birrane@jhuapl.edu</span></a>> <br><b>Cc: </b><a href="mailto:sis-dtn@mailman.ccsds.org">sis-dtn@mailman.ccsds.org</a> <<a href="mailto:sis-dtn@mailman.ccsds.org"><span style='color:#0082BF'>sis-dtn@mailman.ccsds.org</span></a>> <br><b>Subject: </b>[EXT] Canonical CBOR in BPv7 a MUST for block field encoding? <o:p></o:p></p><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 align=left width=0 style='width:6.25in;border-collapse:collapse'><tr style='height:6.0pt'><td width=600 style='width:6.25in;background:#E0E0E0;padding:0in 0in 0in 0in;height:6.0pt'><p class=MsoNormal style='mso-element:frame;mso-element-frame-hspace:1.3pt;mso-element-wrap:around;mso-element-anchor-vertical:paragraph;mso-element-anchor-horizontal:column;mso-height-rule:exactly'><b><span style='font-size:12.0pt;color:red'>APL external email warning: </span></b><span style='font-size:12.0pt;color:black'>Verify sender <a href="mailto:kscott@mitre.org">kscott@mitre.org</a> before clicking links or attachments</span><o:p></o:p></p></td></tr></table><p class=MsoNormal><span style='color:white'><br></span><span style='font-size:12.0pt'> </span> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>The draft-31 spec says:<o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p class=MsoNormal><br><span style='font-size:10.0pt;font-family:"Courier New"'>Cryptographic verification of a block is possible only if the</span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> sequence of octets on which the verifying node computes its hash -</span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> the canonicalized representation of the block - is identical to the</span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> sequence of octets on which the hash declared for that block was</span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> computed. To ensure that blocks are always in canonical</span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> representation when they are transmitted and received, the CBOR</span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> representations of the values of all fields in all blocks <span style='color:red'>must</span></span> <br><span style='font-size:10.0pt;font-family:"Courier New"'> conform to the rules for Canonical CBOR as specified in [</span><a href="https://datatracker.ietf.org/doc/html/rfc8949"><span style='font-size:10.0pt;font-family:"Courier New";color:#0082BF'>RFC8949</span></a><span style='font-size:10.0pt;font-family:"Courier New"'>].</span> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>Note the non-capitalization of the MUST requirement. Was that intended to be capitalized (and is it in the version that the RFC editor sent back)? What are folks thoughts on capitalizing it as part of AUTH48?<o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> v/r,<o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> --keith<o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'> <tt><span style='font-size:10.0pt'>_______________________________________________</span></tt><span style='font-size:10.0pt;font-family:"Courier New"'><br><tt>SIS-DTN mailing list</tt><br><tt><a href="mailto:SIS-DTN@mailman.ccsds.org">SIS-DTN@mailman.ccsds.org</a></tt><br></span><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn"><tt><span style='font-size:10.0pt'>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn</span></tt></a><o:p></o:p></p></div></body></html>