<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;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle20
{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=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><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'>Felix.Flentge@esa.int <Felix.Flentge@esa.int><br><b>Date: </b>Thursday, December 2, 2021 at 1:59 AM<br><b>To: </b>Birrane, Edward J. <Edward.Birrane@jhuapl.edu><br><b>Cc: </b>Dr. Keith L Scott <kscott@mitre.org>, Scott Burleigh <scott.c.burleigh@jpl.nasa.gov>, sis-dtn@mailman.ccsds.org <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></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." <Edward.Birrane@jhuapl.edu></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" <kscott@mitre.org>, "Scott Burleigh" <scott.c.burleigh@jpl.nasa.gov></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'>"sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org></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" <sis-dtn-bounces@mailman.ccsds.org></span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=0 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>sis-dtn@mailman.ccsds.org <<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=600 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:2.25pt;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 kscott@mitre.org 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'>The draft-31 spec says:<o:p></o:p></p><p style='margin:0in'> <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'> <o:p></o:p></p><p style='margin:0in'>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'> <o:p></o:p></p><p style='margin:0in'> v/r,<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'> --keith<o:p></o:p></p><p style='margin:0in'> <o:p></o:p></p><p style='margin:0in'> <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>SIS-DTN@mailman.ccsds.org</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>