Subject: [dtn] BPv7 CDDL and CBOR tagging

From: Brian Sipos <[email-masked]>
Date: Wed, 3 Apr 2019 19:14:26 +0000

This is addressed mostly to Scott B, but also to the WG for discussion,

The CBOR Data Definition Language (CDDL) has now advanced to the "Submitted to IESG" state, and appears to have been refined since the BPv7 Appendix B [1] was originally written. I would like to update the Appendix B to:

  1.  Fix some typos:
     *   The type "dtn-time" should allow negative values so type "int" instead of "uint"
     *   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").
  2.  Indicate some likely places where CBOR tags can be used to augment encoded bundles for troubleshooting. In my mind, the reasonable tag sites are:
     *   Tagging the whole bundle as "#6.55799(bundle) as a sentinel for content-type-scanning tools.
     *   Tagging the "block-type-specific-data" as "encoded-cbor = #6.24(bstr)" when it is in fact CBOR.

Additionally, there was a question brought up to the WG in November 2018 about the almost-typical-but-not-quite use of URIs in the EID encoding. In my first read-through of the draft (having not had direct experience with RFC 5050 implementation), I thought that the EID was an actual URI rather than a compressed form of a small subset of URIs in the "dtn" and "ipn" schemes. I see the value in having a compressed form for some specialized URIs, but there is currently no way to encode as an EID something which is 'just a URI'. Is the intent here that "all EIDs are URIs" but not "all URIs are EIDs"? Is there any value in having an EID code for "just a URI" or is prohibiting a generic URI intentional?

Thanks,
Brian S.

[1]: https://tools.ietf.org/html/draft-ietf-dtn-bpbis-12#appendix-B
[2]: https://tools.ietf.org/html/draft-ietf-cbor-cddl-08#section-3.9

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 14:25:03 +0200

On Apr 3, 2019, at 21:14, Brian Sipos <[email-masked]> wrote:
> 
> 	• Indicate some likely places where CBOR tags can be used to augment encoded bundles for troubleshooting. In my mind, the reasonable tag sites are:
> 		• Tagging the whole bundle as "#6.55799(bundle) as a sentinel for content-type-scanning tools.
> 		• Tagging the "block-type-specific-data" as "encoded-cbor = #6.24(bstr)" when it is in fact CBOR.
> 

Hi Brian,

can you indicate what the purpose of the tagging would be?

Tagging the whole bundle as 55799 would identify it as a CBOR data item, but not yet really as a bundle.  If the purpose is to facilitate working with generic CBOR tools on the data items, that may be useful if there are other formats flying around in the same space the bundle is being used.  If the purpose is to identify this as a bundle, why not go for a specific tag just for bundles?  55798 is still free…  Or any number that is even more visibly tagging (such as 25200, which would be visible in a hex/ASCII dump as ‘bp’, or maybe four-byte or even an eight-byte number).  I understand these tags would be stripped off for actual transmission through a convergence layer?

The encoded-cbor tag (24) is great for identifying embedded CBOR, but what do you do for the other kinds of block-type-specific data?  Sorry, it’s been a while since I looked in detail into the bundle protocol.

(Why is the CDDL in appendix B double-spaced, by the way?)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 14:51:41 +0200

On Apr 3, 2019, at 21:14, Brian Sipos <[email-masked]> 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

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.

Grüße, Carsten

---

From: Brian Sipos <[email-masked]>
Date: Sat, 6 Apr 2019 20:04:05 +0000

Carsten,
My purpose of marking these potentially-tagged items in the CDDL is less for the BP agent encoder implementer to say "where should tags be" but for the bundle troubleshooting / validating tool implementer to give indication of "where may tags be" to have some value. The CDDL itself is all informational, so it's not an issue for the BPv7 spec itself.
The actual value in the tags themselves is not for the BP agent (the agent would just skip over the tags, as neither changes the block-data semantics of the tagged-item), but for troubleshooting with non-BP-specific tools.

I had earlier brought up to the WG the question of whether there is any value in registering a BPv7 media type. That was seen as unnecessary since bundles should only appear in a BP context (either at-rest or on-the-wire) and CBOR encoding itself already has a media type. I think a BP-specific tag would have the same amount of support, which is why my suggestion for a content-type hint on an encoded bundle is just the "yes it's CBOR" tag.

________________________________
From: Carsten Bormann <[email-masked]>
Sent: Saturday, April 6, 2019 08:25
To: Brian Sipos
Cc: [email-masked]; Scott Burleigh
Subject: Re: [dtn] BPv7 CDDL and CBOR tagging

Hi Brian,

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Apr 2019 22:37:12 +0200

On Apr 6, 2019, at 22:04, Brian Sipos <[email-masked]> wrote:
> 
> Carsten,
> My purpose of marking these potentially-tagged items in the CDDL is less for the BP agent encoder implementer to say “where should tags be" but for the bundle troubleshooting / validating tool implementer to give indication of "where may tags be" to have some value.

That is certainly useful.

> The CDDL itself is all informational, so it’s not an issue for the BPv7 spec itself.

By the way, you *could* now go ahead and make it normative, as the CDDL standard has been approved on March 25.

> The actual value in the tags themselves is not for the BP agent (the agent would just skip over the tags, as neither changes the block-data semantics of the tagged-item), but for troubleshooting wi…

OK.  I was also trying to gauge how important saving a few bytes is for you.  If you make the tags optional, there is less reliance diagnostic tools can have on them, but you also don’t have to spend the bytes in situations that are tight.  And v.v.

> I had earlier brought up to the WG the question of whether there is any value in registering a BPv7 media type. That was seen as unnecessary since bundles should only appear in a BP context (either at-rest or on-the-wire) and CBOR encoding itself already has a media type. I think a BP-specific tag would have the same amount of support, which is why my suggestion for a content-type hint on an encoded bundle is just the “yes it's CBOR” tag.

I’m still not entirely sure I’d forego that information (as in do a “file x.x” and get the information “bundle protocol bundle” vs. just “CBOR data item”), but I think I get this point of view, too.

Thank you for the quick reply!

Grüße, Carsten

> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: Brian Sipos <[email-masked]>
Date: Tue, 9 Apr 2019 00:06:19 +0000

On Sat, 2019-04-06 at 14:51 +0200, Carsten Bormann 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).
> 
> 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
> 
> 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?
> 
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

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 9 Apr 2019 01:24:04 +0000

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 <[email-masked]> 
Sent: Monday, April 8, 2019 5:06 PM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]; Burleigh, Scott C (312B) <[email-masked]>
Subject: [EXTERNAL] Re: [dtn] BPv7 CDDL and CBOR tagging

On Sat, 2019-04-06 at 14:51 +0200, Carsten Bormann wrote:
> > 		• A disconnect between the “canonical-block" definition and the 
> > "extension-block" and "payload-block" uses (which are just 
> .within could be used to reference canonical-block (which is currently 
> unused).
> 
> to be made in the second paragraph of the start of section 4).  So the 
> text seems to be trying to say
> 
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- 
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.

---

From: Brian Sipos <[email-masked]>
Date: Wed, 10 Apr 2019 02:17:52 +0000

Scott,
At the bottom of this email is a full CDDL that captures both the
encodings of extension / administrative data as well as the binding
between extension data types and extension block numbers.
I also added restrictions on CRC type code and CRC value data, and used
the socket convention and the "-structure" convention from the pre-RFC
CDDL draft.

I'll leave up to you to decide if this is an over-specialized use of
CDDL. Using the reference "cddl" program to generate randomized data
actually produces near-to-reasonable bundles to my eye, which is nice
validation of the CDDL itself.

The reference program can be tested as in:
$ gem install cddl
$ cddl bpv7.cddl.txt generate 
[[7, 17174, 0, [2, [3026, 451]], [1, 0], [2, [535, 2091]], [4044,
2891], 1070, h'FCDD'], [8, 2593, 229, 2, h'190836', h'C4F3'], [7, 2533,
177, 2, h'820100', h'0504'], [8, 3239, 179, 2, h'1850'], [8, 398, 237,
2, h'183E', h'31261138'], [1, 0, 175, 0,
h'8201848481F581F481F481F51901C6820166766F6C75707482190704190CDA',
h'AFA5']]

One issue that I ran into when testing this: I used this CDDL to
validate some test bundles which I had been generating separately to
test the TCPCL agent. The original CDDL in the draft contains the field
name "total-application-data-length" which also appears several times
in the draft as "total application data unit length" in the statments.
But I don't see that field listed in Section 4.2.2. Is there a missing
field in that section, or is that field no longer present and the other
text is inaccurate?

Thanks,
Brian S.

On Tue, 2019-04-09 at 01:24 +0000, Burleigh, Scott C (312B) wrote:
> 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

start = bundle / #6.55799(bundle)

; Times before 2000 are invalid
dtn-time = uint

; CRC enumerated type
crc-type = 0 / 1 / 2
; Either 16-bit or 32-bit
crc-value = (bstr .size 2) / (bstr .size 4)

creation-timestamp = [dtn-time, sequence: uint]

eid = $eid-choice .within eid-structure
eid-structure = [
  uri-code: uint,
  SSP: any
]
$eid-choice /= [
  uri-code: 1,
  SSP: (tstr / 0)
]
$eid-choice /= [
  uri-code: 2,
  SSP: [
    nodenum: uint,
    servicenum: uint
  ]
]

bundle-control-flags = uint .bits bundleflagbits
bundleflagbits = &(
  reserved: 15
  reserved: 14
  reserved: 13
  bundle-deletion-status-reports-are-requested: 12
  bundle-delivery-status-reports-are-requested: 11
  bundle-forwarding-status-reports-are-requested: 10
  reserved: 9
  bundle-reception-status-reports-are-requested: 8
  bundle-contains-a-Manifest-block: 7
  status-time-is-requested-in-all-status-reports: 6
  user-application-acknowledgement-is-requested: 5
  reserved: 4
  reserved: 3
  bundle-must-not-be-fragmented: 2
  payload-is-an-administrative-record: 1
  bundle-is-a-fragment: 0
)

block-control-flags = uint .bits blockflagbits
blockflagbits = &(
  reserved: 7
  reserved: 6
  reserved: 5
  reserved: 4
  bundle-must-be-deleted-if-block-cannot-be-processed: 3
  status-report-must-be-transmitted-if-block-cannot-be-processed: 2
  block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1
  block-must-be-replicated-in-every-fragment: 0
)

primary-block = [
  version: 7,
  bundle-control-flags,
  crc-type,
  destination: eid,
  source-node: eid,
  report-to: eid,
  creation-timestamp,
  lifetime: uint,
  ? (
    fragment-offset: uint,
;    total-application-data-length: uint,
  )
  ? crc-value,
]

; Abstract shared structure of all non-primary blocks
canonical-block-structure = [
  block-type-code: uint,
  block-number: uint,
  block-control-flags,
  crc-type,
  ; Each block type defines the content within the bytestring
  block-type-specific-data,
  ? crc-value
]
block-type-specific-data = bstr / #6.24(bstr)
; Extension block type, which does not specialize any more than the
code/number
extension-block = $extension-block-structure .within canonical-block-
structure
$extension-block-structure = [
  block-type-code: (uint .gt 1),
  extension-block-number,
  block-control-flags,
  crc-type,
  ($extension-block-data .within block-type-specific-data)
  ? crc-value
]
extension-block-number = (uint .ne 0)
; Payload block type
payload-block = payload-block-structure .within canonical-block-
structure
payload-block-structure = [
  block-type-code: 1,
  block-number: 0,
  block-control-flags,
  crc-type,
  ($payload-block-data .within block-type-specific-data)
  ? crc-value
]

; Arbitrary payload data
$payload-block-data /= bstr

; Administrative record as a payload data specialization
$payload-block-data /= block-type-specific-data .cbor admin-record
; Only one defined record type
  source-node-eid: eid,
  ? timestamp: dtn-time
]

; Previous Node extension block
$extension-block-structure /= [
  block-type-code: 7,
  extension-block-number,
  block-control-flags,
  crc-type,
  (block-type-specific-data .cbor ext-data-previous-node)
  ? crc-value
]
ext-data-previous-node = eid

; Bundle Age extension block
$extension-block-structure /= [
  block-type-code: 8,
  extension-block-number,
  block-control-flags,
  crc-type,
  (block-type-specific-data .cbor ext-data-bundle-age)
  ? crc-value
]
ext-data-bundle-age = uint

; Hop Count extension block
$extension-block-structure /= [
  block-type-code: 9,
  extension-block-number,
  block-control-flags,
  crc-type,
  (block-type-specific-data .cbor ext-data-hop-count)
  ? crc-value
]
ext-data-hop-count = [
  hop-limit: uint,
  hop-count: uint
]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Apr 2019 10:58:15 +0200

(CBOR WG: replying on
https://mailarchive.ietf.org/arch/msg/dtn/3qn38t9lYR_e-7IicyARKfimLPk
as this is an interesting use case of specialization.)

Thanks!  This already looks pretty good (once I fix the three cases of line-wrapping).

> On Apr 10, 2019, at 04:17, Brian Sipos <[email-masked]> wrote:
> 

For me, the tool has the problem that it can’t generate

With the former being

What you are trying to say is that the bstr in there conforms to “.cbor ext-data-hop-count”, but the tool is applying the .cbor to the choice, and its brain is too small for that.

I think some unraveling is required to properly address this.

I would probably define a generic for this (sorry for the long names):

optionally-tagged—embedded-cbor<T> = T / #6.24(T)

block-type-specific-data = optionally-tagged-embedded-cbor<bstr>

And then, e.g.:

$extension-block-structure /= [
 block-type-code: 7,
 extension-block-number,
 block-control-flags,
 crc-type,
 optionally-tagged-embedded-cbor<(bstr .cbor ext-data-previous-node)>
 ? crc-value
]

OK, for readability maybe add

embedded-cbor-optionally-tagged<E> = optionally-tagged-embedded-cbor<bstr .cbor E>

and then 

$extension-block-structure /= [
 block-type-code: 7,
 extension-block-number,
 block-control-flags,
 crc-type,
 embedded-cbor-optionally-tagged<ext-data-previous-node>
 ? crc-value
]

That is not wonderful, as it repeats the fact that the thing is optionally tagged “embedded CBOR” all over the individual block type definitions, but it starts enabling focus on the actual structure again.

(I’m still not entirely convinced that the tag 24 here is very useful, but I’m trying to play along the design.)

Grüße, Carsten

PS.: If I were writing this, I’d also add

extension-block-of<N, T> = [
 block-type-code: N,
 extension-block-number,
 block-control-flags,
 crc-type,
 embedded-cbor-optionally-tagged<T>
 ? crc-value
]

And then just say

$extension-block-structure /= extension-block-of<7, ext-data-previous-node>

but how much abstraction to add is a matter of preference; this at least gets rid of the “sprinkle the structure all over the place” problem.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 10 Apr 2019 15:07:45 +0000

Brian, thanks, this is great!  I'll insert the revised CDDL and re-post.

I think "total application data unit length" was erroneously deleted from section 4.2.2 a couple of revs back, but it was restored as of version 13 (January).

Scott

-----Original Message-----
From: Brian Sipos <[email-masked]> 
Sent: Tuesday, April 9, 2019 7:18 PM
To: Burleigh, Scott C (312B) <[email-masked]>; Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dtn] BPv7 CDDL and CBOR tagging

Scott,
At the bottom of this email is a full CDDL that captures both the encodings of extension / administrative data as well as the binding between extension data types and extension block numbers.
I also added restrictions on CRC type code and CRC value data, and used the socket convention and the "-structure" convention from the pre-RFC CDDL draft.

I'll leave up to you to decide if this is an over-specialized use of CDDL. Using the reference "cddl" program to generate randomized data actually produces near-to-reasonable bundles to my eye, which is nice validation of the CDDL itself.

The reference program can be tested as in:
$ gem install cddl
$ cddl bpv7.cddl.txt generate
[[7, 17174, 0, [2, [3026, 451]], [1, 0], [2, [535, 2091]], [4044, 2891], 1070, h'FCDD'], [8, 2593, 229, 2, h'190836', h'C4F3'], [7, 2533, 177, 2, h'820100', h'0504'], [8, 3239, 179, 2, h'1850'], [8, 398, 237, 2, h'183E', h'31261138'], [1, 0, 175, 0, h'8201848481F581F481F481F51901C6820166766F6C75707482190704190CDA',
h'AFA5']]

One issue that I ran into when testing this: I used this CDDL to validate some test bundles which I had been generating separately to test the TCPCL agent. The original CDDL in the draft contains the field name "total-application-data-length" which also appears several times in the draft as "total application data unit length" in the statments.
But I don't see that field listed in Section 4.2.2. Is there a missing field in that section, or is that field no longer present and the other text is inaccurate?

Thanks,
Brian S.

On Tue, 2019-04-09 at 01:24 +0000, Burleigh, Scott C (312B) wrote:
> 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 

; CRC enumerated type
crc-type = 0 / 1 / 2

bundle-control-flags = uint .bits bundleflagbits bundleflagbits = &(
  reserved: 15
  reserved: 14
  reserved: 13

block-control-flags = uint .bits blockflagbits blockflagbits = &(
  reserved: 7
  reserved: 6
  reserved: 5
  reserved: 4

primary-block = [
  version: 7,
  bundle-control-flags,
  crc-type,
  destination: eid,
  source-node: eid,
  report-to: eid,
  creation-timestamp,
  lifetime: uint,
  ? (
    fragment-offset: uint,

; Abstract shared structure of all non-primary blocks canonical-block-structure = [
  block-type-code: uint,
  block-number: uint,
  block-control-flags,
  crc-type,
  ; Each block type defines the content within the bytestring
  block-type-specific-data,
  ? crc-value
]
block-type-specific-data = bstr / #6.24(bstr) ; Extension block type, which does not specialize any more than the code/number extension-block = $extension-block-structure .within canonical-block- structure $extension-block-structure = [
  block-type-code: (uint .gt 1),
  extension-block-number,
  block-control-flags,
  crc-type,
  ($extension-block-data .within block-type-specific-data)
  ? crc-value
]
extension-block-number = (uint .ne 0)
; Payload block type
payload-block = payload-block-structure .within canonical-block- structure payload-block-structure = [
  block-type-code: 1,
  block-number: 0,
  block-control-flags,
  crc-type,
  ($payload-block-data .within block-type-specific-data)
  ? crc-value
]

; Arbitrary payload data

; Administrative record as a payload data specialization $payload-block-data /= block-type-specific-data .cbor admin-record admin-record = $admin-record .within admin-record-structure admin-record-structure = [
  record-type-code: uint,
  record-content: any
]
; Only one defined record type
$admin-record /= [1, status-record-content] status-record-content = [
  bundle-status-information,
  status-report-reason-code: uint,
  source-node-eid: eid,
  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
]

---

From: Brian Sipos <[email-masked]>
Date: Wed, 10 Apr 2019 16:50:48 +0000

Scott and Carsten,
I'm not as familiar with some newish behavior of CDDL as I would like to be, so didn't even realize the Generics behavior was available. I agree with the last that the canonical block should be written as a generic that the payload/extension blocks use.

Below is an updated CDDL which simplifies things and adds back in the total application data unit length field. It fully validates randomly generated bundles from a different application, which is a good sign. I also trimmed the line length to fit within 80 characters to avoid some formatting issues. I'm adding CODE tags similar to recommended in RFC8407, I wonder if something similar would be useful for CDDL embeds...

<CODE BEGINS> file "bpv7.cddl"

dtn-time = uint

; CRC enumerated type

crc-type = 0 / 1 / 2

eid-structure = [

  uri-code: uint,

  SSP: any

]

$eid-choice /= [

  uri-code: 1,

  SSP: (tstr / 0)

]

$eid-choice /= [

  uri-code: 2,

  SSP: [

    nodenum: uint,

    servicenum: uint

  ]

]

; The root bundle array

primary-block = [

  version: 7,

  bundle-control-flags,

  crc-type,

  destination: eid,

  source-node: eid,

  report-to: eid,

  creation-timestamp,

  lifetime: uint,

  ? (

    fragment-offset: uint,

    total-application-data-length: uint,

  )

  ? crc-value,

]

bundleflagbits = &(

  reserved: 15,

  reserved: 14,

  reserved: 13,

  bundle-deletion-status-reports-are-requested: 12,

  bundle-delivery-status-reports-are-requested: 11,

  bundle-forwarding-status-reports-are-requested: 10,

  reserved: 9,

  bundle-reception-status-reports-are-requested: 8,

  bundle-contains-a-Manifest-block: 7,

  status-time-is-requested-in-all-status-reports: 6,

  user-application-acknowledgement-is-requested: 5,

  reserved: 4,

  reserved: 3,

  bundle-must-not-be-fragmented: 2,

  payload-is-an-administrative-record: 1,

  bundle-is-a-fragment: 0

)

  block-type-code: uint,

  block-number: uint,

  block-control-flags,

  crc-type,

  ? crc-value

]

blockflagbits = &(

  reserved: 7,

  reserved: 6,

  reserved: 5,

  reserved: 4,

  bundle-must-be-deleted-if-block-cannot-be-processed: 3,

  status-report-must-be-transmitted-if-block-cannot-be-processed: 2,

  block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1,

)

; Actual CBOR data embedded in a bytestring, with optional tag to indicate so

embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item)

; Extension block type, which does not specialize other than the code/number

extension-block = $extension-block-structure .within canonical-block-structure

; Generic shared structure of all non-primary blocks

extension-block-use<CodeValue, BlockData> = [

  block-type-code: CodeValue,

  block-number: (uint .ne 0),

  block-control-flags,

  crc-type,

  BlockData,

  ? crc-value

]

; Payload block type

payload-block = payload-block-structure .within canonical-block-structure

  block-type-code: 1,

  block-number: 0,

  block-control-flags,

  crc-type,

  $payload-block-data,

  ? crc-value

]

; Arbitrary payload data, including non-CBOR bytestring

$payload-block-data /= block-type-specific-data

$payload-block-data /= embedded-cbor<admin-record>

  record-type-code: uint,

  record-content: any

]

  source-node-eid: eid,

  ? (

  )

]

]

status-info-content = [

  status-indicator: bool,

  ? timestamp: dtn-time

]

$extension-block-structure /=

  extension-block-use<7, embedded-cbor<ext-data-previous-node>>

$extension-block-structure /=

  extension-block-use<8, embedded-cbor<ext-data-bundle-age>>

$extension-block-structure /=

  extension-block-use<9, embedded-cbor<ext-data-hop-count>>

ext-data-hop-count = [

  hop-limit: uint,

  hop-count: uint

]

<CODE ENDS>

On Wed, 2019-04-10 at 15:07 +0000, Burleigh, Scott C (312B) wrote:
Brian, thanks, this is great!  I'll insert the revised CDDL and re-post.

Scott

-----Original Message-----
From: Brian Sipos <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, April 9, 2019 7:18 PM
To: Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>; Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [dtn] BPv7 CDDL and CBOR tagging

Scott,

Thanks,
Brian S.

Scott

; CRC enumerated type
crc-type = 0 / 1 / 2

primary-block = [
  version: 7,
  bundle-control-flags,
  crc-type,
  destination: eid,
  source-node: eid,
  report-to: eid,
  creation-timestamp,
  lifetime: uint,
  ? (
    fragment-offset: uint,

; Arbitrary payload data

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Brian Sipos <[email-masked]>
Date: Sat, 13 Apr 2019 16:13:45 +0000

Rather than embedding more in email, I've uploaded a revised CDDL (minor typos with commas, and
named the crc-type values) to [1]. This should avoid any line/spacing/etc. issues with email text
transport.

[1]: https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/blob/develop/bpv7.cddl

On Wed, 2019-04-10 at 15:07 +0000, Burleigh, Scott C (312B) wrote:
> I think "total application data unit length" was erroneously deleted from section 4.2.2 a couple
> of revs back, but it was restored as of version 13 (January).
> 
> Scott
> 
> At the bottom of this email is a full CDDL that captures both the encodings of extension /
> administrative data as well as the binding between extension data types and extension block
> numbers.
> I also added restrictions on CRC type code and CRC value data, and used the socket convention and
> the "-structure" convention from the pre-RFC CDDL draft.
> 
> I'll leave up to you to decide if this is an over-specialized use of CDDL. Using the reference
> "cddl" program to generate randomized data actually produces near-to-reasonable bundles to my eye,
> which is nice validation of the CDDL itself.
> 
> [[7, 17174, 0, [2, [3026, 451]], [1, 0], [2, [535, 2091]], [4044, 2891], 1070, h'FCDD'], [8, 2593,
> 229, 2, h'190836', h'C4F3'], [7, 2533, 177, 2, h'820100', h'0504'], [8, 3239, 179, 2, h'1850'],
> [8, 398, 237, 2, h'183E', h'31261138'], [1, 0, 175, 0,
> One issue that I ran into when testing this: I used this CDDL to validate some test bundles which
> I had been generating separately to test the TCPCL agent. The original CDDL in the draft contains
> the field name "total-application-data-length" which also appears several times in the draft as
> "total application data unit length" in the statments.
> But I don't see that field listed in Section 4.2.2. Is there a missing field in that section, or
> is that field no longer present and the other text is inaccurate?
> 
> Thanks,
> Brian S.
> 
> block-type-specific-data = bstr / #6.24(bstr) ; Extension block type, which does not specialize
> any more than the code/number extension-block = $extension-block-structure .within canonical-
> block- structure $extension-block-structure = [
> ; Administrative record as a payload data specialization $payload-block-data /= block-type-
> specific-data .cbor admin-record admin-record = $admin-record .within admin-record-structure