Internet-Draft CDDL models for some existing RFCs August 2023
Bormann Expires 28 February 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-bormann-cbor-rfc-cddl-models-02
Published:
Intended Status:
Informational
Expires:
Author:
C. Bormann
Universität Bremen TZI

CDDL models for some existing RFCs

Abstract

A number of CBOR- and JSON-based protocols have been defined before CDDL was standardized or widely used.

This short draft records some CDDL definitions for such protocols, which could become part of a library of CDDL definitions available for use in CDDL2 processors. It focuses on CDDL in (almost) published IETF RFCs.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 February 2024.

Table of Contents

1. Introduction

(Please see abstract.) Add in [STD94] [STD90] [RFC8610] [RFC9165] [I-D.bormann-cbor-cddl-more-control]

2. CDDL definitions for (almost) published RFCs

This section is intended to have one subsection for each CDDL data model presented for an existing RFC. As a start, it is fleshed out with three such data models.

2.1. RFC 7071

Appendix H of [RFC8610] contains two CDDL definitions for [RFC7071], which are not copied here. Typically, the compact form would be used in applications using the RFC 7071 format; while the extended form might be useful to cherry-pick features of RFC 7071 into another protocol.

2.2. RFC 8366

[RFC8366] defines a data model for a "Voucher Artifact", which can be represented in CDDL as:

voucher-artifact = {
  "ietf-voucher:voucher": {
    created-on: yang$date-and-time
    ? (
        expires-on: yang$date-and-time
        ? last-renewal-date: yang$date-and-time
        //
        nonce: json-binary<bytes .size (8..32)>
      )
    assertion: assertion
    serial-number: text
    ? idevid-issuer: json-binary<bytes>
    pinned-domain-cert: json-binary<bytes>
    ? domain-cert-revocation-checks: bool
  }
}

assertion = "verified" / "logged" / "proximity"

yang$date-and-time = text .regexp cat3<"[0-9]{4}-[0-9]{2}-[0-9]{2}T",
                            "[0-9]{2}:[0-9]{2}:[0-9]{2}([.][0-9]+)?",
                            "(Z|[+-][0-9]{2}:[0-9]{2})">

cat3<A,B,C> = (A .cat B) .cat C

json-binary<T> = text .b64c T

The two examples in the RFC can be validated with this little patchup script:

sed -e s/ue=/uQ=/ -e s/'"true"'/true/ | cddl rfc8366.cddl vp -

2.3. RFC 9457

[RFC9457] defines a simple data model that is reproduced in CDDL here:

problem-object = {
  ? type: preferably-absolute-uri
  ? title: text
  ? status: 100..599
  ? detail: text
  ? instance: preferably-absolute-uri
  * text .feature "problem-object-extension" => any
}

; RECOMMENDED: absolute URI or at least absolute path:
preferably-absolute-uri = ~uri

Note that Appendix B of [RFC9290] also defines a CBOR-specific data model that may be useful for tunneling [RFC7807] or [RFC9457] problem details in [RFC9290] Concise Problem Details.

2.4. YANG-SID

The RFC to be published out of [YANG-SID] defines a data model for a "SID file" in YANG, to be transported as a YANG-JSON instance.

An equivalent CDDL data model is given here:

sid-file = {
  "ietf-sid-file:sid-file": {
    module-name: yang$yang-identifier
    ? module-revision: revision-identifier
    ? sid-file-version: sid-file-version-identifier
    ? sid-file-status: "unpublished" / "published"
    ? description: text
    ? dependency-revision: [* dependency-revision]
    ? assignment-range: [* assignment-range]
    ? item: [*item]
  }
}

rep<RE>=cat3<"(", RE, ")*">
opt<RE>=cat3<"(", RE, ")?">
cat3<A,B,C> = (A .cat B) .cat C

id-re = "[a-zA-Z_][a-zA-Z0-9\\-_.]*"
yang$yang-identifier = text .regexp id-re
revision-identifier = text .regexp "[0-9]{4}-[0-9]{2}-[0-9]{2}"
sid-file-version-identifier = uint .size 4
sid = text .decimal (0..0x7fffffffffffffff); uint63 as text string
plus-id<Prefix> = Prefix .cat id-re
schema-node-re = cat3<plus-id<"/">, plus-id<":">, ; qualified
                      rep<plus-id<"/"> .cat       ; optionally
                          opt<plus-id<":">> > >     ; qualified
schema-node-path = text .regexp schema-node-re

dependency-revision = {
  module-name: yang$yang-identifier
  module-revision: revision-identifier
}

assignment-range = {
  entry-point: sid
  size: sid
}

item = {
  ? status: "stable" / "unstable" / "obsolete"
  (
    namespace: "module" / "identity" / "feature"
    identifier: yang$yang-identifier
  //
    namespace: "data"
    identifier: schema-node-path
  )
  sid: sid
}

3. IANA Considerations

This document makes no requests of IANA.

4. Security considerations

The security considerations of [RFC8610], [RFC9165], [I-D.bormann-cbor-cddl-more-control], [STD94] and [STD90] apply. This collection of CDDL models is not thought to create new security considerations. Errors in the models could -- if we knew of them, we'd fix those errors instead of explaining their security consequences in this section.

5. References

5.1. Normative References

[I-D.bormann-cbor-cddl-more-control]
Bormann, C., "More Control Operators for CDDL", Work in Progress, Internet-Draft, draft-bormann-cbor-cddl-more-control-01, , <https://datatracker.ietf.org/doc/html/draft-bormann-cbor-cddl-more-control-01>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9165]
Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, , <https://www.rfc-editor.org/rfc/rfc9165>.
[STD90]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[STD94]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.

5.2. Informative References

[RFC7071]
Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, DOI 10.17487/RFC7071, , <https://www.rfc-editor.org/rfc/rfc7071>.
[RFC7807]
Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, , <https://www.rfc-editor.org/rfc/rfc7807>.
[RFC8366]
Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, "A Voucher Artifact for Bootstrapping Protocols", RFC 8366, DOI 10.17487/RFC8366, , <https://www.rfc-editor.org/rfc/rfc8366>.
[RFC9290]
Fossati, T. and C. Bormann, "Concise Problem Details for Constrained Application Protocol (CoAP) APIs", RFC 9290, DOI 10.17487/RFC9290, , <https://www.rfc-editor.org/rfc/rfc9290>.
[RFC9457]
Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, , <https://www.rfc-editor.org/rfc/rfc9457>.
[YANG-SID]
Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-20, , <https://datatracker.ietf.org/doc/html/draft-ietf-core-sid-20>.

Acknowledgements

TBD

Author's Address

Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany