Re: [dtn] BPv7 CDDL and CBOR tagging

["Burleigh, Scott C (312B)" <[e-mail]>]

Guys, please feel free to send me an updated CDDL expression of Bundle Protocol version 7; I will gladly include it in the document.

My one comment is that the type dtn-time is correctly defined as uint; it should NOT be changed to int, as negative values are not allowed.  If you can spot an instance in the spec where dtn-time is characterized as a signed integer, please let me know and I will correct it.

Scott

-----Original Message-----
From: Brian Sipos <[e-mail]> 
Sent: Monday, April 8, 2019 5:06 PM
To: Carsten Bormann <[e-mail]>
Cc: [e-mail]; Burleigh, Scott C (312B) <[e-mail]>
Subject: [EXTERNAL] Re: [dtn] BPv7 CDDL and CBOR tagging

On Sat, 2019-04-06 at 14:51 +0200, Carsten Bormann wrote:
> On Apr 3, 2019, at 21:14, Brian Sipos <[e-mail]> wrote:
> > 
> > 		• A disconnect between the “canonical-block" definition and the 
> > "extension-block" and "payload-block" uses (which are just 
> > canonical-block type with value restrictions, probably using 
> > ".within").
> 
> Right, it would help to define payload-block and extension-block, and 
> .within could be used to reference canonical-block (which is currently 
> unused).
> 
> The text of 4.2.1 in -12 starts with a paragraph that ends in:
> 
>    The last item of
>    the array SHALL be a CBOR “break" stop code.
> 
> A break stop code is not a data item, but is the part of an 
> indefinite-length array encoding that ends it (the same change needs 
> to be made in the second paragraph of the start of section 4).  So the 
> text seems to be trying to say
> 
>    bundle = [primary-block, *canonical-block]
> 
> The CDDL in Appendix B is more specific:
> 
>    bundle = [primary-block, *extension-block, payload-block]
> 
> So there must be a payload-block as the last data item, and zero or 
> more extension-blocks preceding it, which according to the text in
> 4.2.1 all need to be of canonical-block structure.
> 
> Is there something from the text about extension-block and payload- 
> block that could be encoded in a CDDL definition of these two?
> 
> So far, I have found text that makes be believe
> 
> payload-block = ([block-type-code: 1, canonical-block-common, ?crc]) 
> .within canonical-block
> 
> and
> 
> extension-block = ([block-type-code: (uint .ne 1), canonical-block- 
> common, ?crc]) .within canonical-block
> 
I believe that this is correct, and there is one more constraint that the payload block itself always has block number zero [1]. Though I don't know how much value there is in adding that to the CDDL since it really doesn't seem to have any negative effects if the payload block happens to have some other block number...

> BTW, the CDDL for primary block ends in three optional components, two 
> of which are of the same type, so it is not clear whether you have a 
> primary-block with a fragment-offset but without a total- 
> application-data-length or a primary block with a total-application- 
> data-length but no fragment-offset.
> 
Those last three items are not determined via type introspection but by checking the bundle flags. So it's not something that seems like CDDL can encode or check (so violations may result in interesting or confusing errors from a generic validator).

Since the two optional uint values must come together, the existing CDDL of:
                 lifetime: uint,
                 ? fragment-offset: uint,
                 ? total-application-data-length: uint,
                 ? crc,
could more accurately be represented by the CDDL:
                 lifetime: uint,
                 ? (
                   fragment-offset: uint,
                   total-application-data-length: uint
                 ),
                 ? crc,


This also brings up the administrative record, which does not yet have a CDDL representation. The following seems like it should be a decent start to that. This uses the CDDL notion of an abstract "socket"
prefixed with a dollar sign.

  admin-record = $admin-record .within admin-record-structure
  admin-record-structure = [
    record-type-code: uint,
    record-content: any
  ]

  $admin-record /= [1, status-record-content]
  status-record-content = [
    bundle-status-information,
    status-report-reason-code: uint,
    source-node-eid: eid-generic,
    subject-creation-timestamp: creation-timestamp,
    ? (
      subject-payload-offset: uint,
      subject-payload-length: uint
    )
  ]
  bundle-status-information = [
    reporting-node-received-bundle: status-info-content,
    reporting-node-forwarded-bundle: status-info-content,
    reporting-node-delivered-bundle: status-info-content,
    reporting-node-deleted-bundle: status-info-content
  ]
  status-info-content = [
    status-indicator: bool,
    ? timestamp: dtn_time
  ]

[1]: https://tools.ietf.org/html/draft-ietf-dtn-bpbis-12#section-4.2.3