# CBOR at IETF116 {#cbor-at-ietf116} ## Agenda {#agenda} * Introduction, agenda. Chairs, 3'. * Brief overview of documents not discussed today. Chairs, 2'. * cbor-packed: Ongoing work. * Carsten's bag of pointers * Usable Formal Methods pRG * Profiling: dCBOR and cose-profiles * [bormann-cbor-edn-literals][1] and its new media type registration * DISPATCH sent dCBOR ([mcnally-deterministic-cbor][2]) here. * [ietf-cbor-time-tag][3]. CB, 5'. Goals: Raise awareness. Can we wait for SEDATE before completing? Do we need signed time stamps in there? * [lenders-dns-cbor][4]. ML, 10'. Goals: Report progress, gather feedback. * CDDL-2 block. CB, 40' * [bormann-cbor-cddl-more-control][5] * [bormann-cbor-update-8610-grammar][6] * [bormann-cbor-cddl-modules][7] Goals for the above: Discuss, consider WGA * [bormann-cbor-cddl-2-draft][8] * [bormann-cbor-cddl-freezer][9] * CBORPath Goals for the above: Report on status, discussion ## Minutes {#minutes} ### Chairs introduction {#chairs-introduction} Minute takers: Marco Tiloca BL doing introduction CA giving a document status update CA: Carsten will cover one on deterministic CBOR; then we have Packed CBOR also progressing, we have to finish the part on the table setups based on requirements from other documents using Packed CBOR. ### Carsten's bag of pointers {#carstens-bag-of-pointers} CB presenting * Usable Formal Methods pRG met yesterday; they not only talk about validation but also specification (which CDDL is about), we'll be in contact with them. * "profiles" CB (p2): many asks for "profiles", the -deterministic-cbor document is an example of those, -cose-profiles is another one. JPM: What's the difference between -deterministic-cbor and the CBOR standard? What seems to be only missing from the standard is implementation. CB: The difference is not much, it expands on RFC 8949. But it also takes some decisions, e.g., the application should not differ between integers and protocol values. JPM: Ok; more focus on deterministic CBOR can be good, maybe we can get an implementation. CB: One can always re-encode and compare against what received to check about determinism. JPM: And that's suboptimal. CB: Can't be done much better. JPM (on chat): Regarding deterministic CBOR implementations. I would assume that an implementation that receives CBOR, does D = decode(CBOR), and then checks that encode(D) == CBOR uses twice as many clock cycles as an optimal implementation and uses significantly more memory as CBOR, D, and encode(D) have to be in memory at the same time. Or am I missing something? The described implementation is however likely optimal in code size if you want to support both deterministic and non-deterministic CBOR. CA (on chat): As I understand, Carsten's implementation is a Ruby one. If cycles matter to you, that's not what you'd use. CB (p3): Image from hackathon... This can get very ugly very quickly. Maybe we need to invent some concepts, such as profiles in common usage or whatsoever. Proposing to do this in interims. That people come here indicates it's needed. CB (p4): Media type for EDN? (Everyone is using *extended* diagnostic notation these days). In 2013, we were wary about people thinking of the DN as an interchange format -- not the intention, so we intentionally we did not register a media type. Now that is no longer a concern. Currently in EDN-literals. Document could go forward, I think it's convenient to pack them. Please have a look, draft is fresh. Once WG document, we can discuss the registration policies in detail. CB: This slide is implying a hope for call for adoption. ### [ietf-cbor-time-tag][3] {#ietf-cbor-time-tag} CB presenting CB: Adopted some time ago, had no rush completing (tags are registered). Completed WGLC in January, all comments should have been addressed in -05 submitted before the cut-off. CB: Wish to synch with the companion document in SEDATE, which should have been unblocked after a charter update. ### [lenders-dns-cbor][4] {#lenders-dns-cbor} ML presenting ML: When running DNS over CoAP (even with DNS compression), we quickly ran into message fragmentation. Hence this work for encoding in CBOR. ML (p6): showing updates since IETF 115 (mostly based on feedback from Carsten (now co-author), Ben and Vadim. Updated format of queries, aligned with that of responses. ML (p7): Ongoing work on using Packed CBOR (specific algorithms left to the implementation); todo: examples with compression, comparison of different encoding alternatives ML (p8): plan to implement and evaluate, also with more investigation on Packed CBOR. CA: Have people looked at the DNS CBOR draft? It'd benefit from feedback. Please have a look at the draft. ML: I second that. CB: Little incencentives now with 5 authors, but please give comments. ### CDDL 2 block {#cddl-2-block} CB presenting CB: Looking at the prev' presentation: It seems to be a pattern to extract the data model out of older formats and express them in CBOR. #### Overview {#overview} CB (p7): CDDL 2.0 was a placeholder for things, now we have better understanding of what we want to do. Most of these documents are now close to be ready for a WG adoption call. Showing time plan for the documents to follow this year. CB (p7): 8610 does all the ABNF changes. Mostly implemented (eg. b/c you can't do it anyway w/o considering the errata). CB: control-operators we already did once (RFC9165), just another set. Both can be done before IETF117 (San Francisco). CB: cddl-modules (what I call "2.0"). More complex than the above. Good thing: Implemented. People may still want this or that in it. Programme for this year, should be done by IETF118 (Prague) CB (p8): Showing plan for CDDL 2.5, intended for 2024. More info intended to be included in the CDDL model, e.g., through "functionalities". Freezer has examples. CB (p9): (minute takers' remark from seeing these slides earlier: I:=Informational, S:=Standars-Track, B: =BCP) CDDL-in-JSON to be changed once more (and then decide whether it's to be a document or wiki). cddl-models is for use with 2.0. Literals in CDDL to be developed together with edn-literals. New document on using CBOR in drafts before codepoints get assigned; got reviews to process, this can be a BCP. Finally, document on csv. #### 8610-grammar {#8610-grammar} CB (p10): small updates and bug fixes. CB: Proposing adoption #### more-controls {#more-controls} CB (p11): list of new, proposed controls. CB: Already thinking about YANG-CBOR encoded in there, will likely make a proposal. #### Module {#module} CB (p12): concatenating files with backward compatibility CB (p13): two types of usage environments: in the project (;#include) or between projects (;#import); supporting for aliasing and scope narrowing. #### CDDL 2.0 status {#cddl-20-status} CB (p14): implementation status for the cddlc tool, possible to combine with the cddl tool. Please try the tool. Feedback suggests that this is well understood. CA: I'd like a round of adoption show-of-hands at the end of the session, about the three documents discussed before. ### CDDL 2.5 {#cddl-25} CB (p15): Annotation changes "yes-no" validation to "what-is-what" annotation. The next step will be transformation. CB (p16): Proposed syntax for annotations. (s/unit/uint/ in slides). CB (p17): CBORPath is good input to consider (see issue #90 on the Github). JSONPath will soon be in WGLC. YANG uses XPath because it was originally XML based. We could use XPath 3.1, but wouldn't be a big fan. Might still happen if we don't do something. CB (p18): MT: What if the value can be integer or string, some registries can do that. Does it impact? CB: This is a straw man proposal; the hard part will be converting the textual information (sequence-of-digits) into the data model. CB (p19): everything here (module structure etc) we probably want to do with ABNF as well. BL: Questions / discussions? ## Administrative business {#administrative-business} * WGA calls * edn-literals BL: objections on adopting this document? (heard none) BL: We'll take it to the mailing list. * cddl-modules * 8610-grammar * more-controls BL: objections on adopting these three documents? (heard none) BL: We'll take it to the mailing list. Chris Lemmons (on chat): Please adopt these. :) AR: Hard for a newcomer to understand the distinction between "import" and "include". CB: They'd have to learn these. AR: Is that distinction necessary? CB: import alone is enough, but there is a class of errors you can avoid by doing some this way and some that way. include is for within your project (ensuring consistency), and import when using a library. Import also prevents recursion. BL: We'll post to the list to confirm these adoptions. Chris Lemmons: Ability to import from documents that are not necessarily RFCs -- it's used in a variety of places. Should be useful there as well. CB: Current definition cheats there. Thing right of an import is "a name". How that is mapped is defined by the tool. cddlc just takes a PATH-like environment variable. The last item there is a collection of data the tool has imported from the RFCs. If you have a draft, a recent copy will be in a place referenced there. Hard to specify versions, given drafts can move forward (the only way to not break things as drafts move forward is to place them in a place you control). Don't think the spec can solve that, but would love to learn about ways to do it. CL: I'll think more about this, but it's going in a good direction. Can discuss as work progresses. CB: I always rsync the drafts collection, that's in the include path. Esko Dijk (on chat): CDDL import: RFCs with errata are another risk factor here. * Weekly resuming April 19th? BL: Coordinated with CoRE and we plan to keep the same schedule. Biweekly starting from April 19. Does anyone have a problem with that? (none heard) [1]: https://datatracker.ietf.org/doc/draft-bormann-cbor-edn-literals/ [2]: https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/ [3]: https://datatracker.ietf.org/doc/draft-ietf-cbor-time-tag/ [4]: https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/ [5]: https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-more-control/ [6]: https://datatracker.ietf.org/doc/draft-bormann-cbor-update-8610-grammar/ [7]: https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-modules/ [8]: https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-2-draft/ [9]: https://datatracker.ietf.org/doc/draft-bormann-cbor-cddl-freezer/