Re: [dtn] BPv7 CDDL and CBOR tagging

[Brian Sipos <[e-mail]>]

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