CBOR at IETF119

Materials link: https://datatracker.ietf.org/meeting/119/session/cbor

Action items

• Ping RATS/FFT(?) for feedback on more-control
• LL: WGLC comment on .cbordet
• April interim: plan YANG-CBOR
• (from chat): Find shepherd for more-control

Agenda

Brief introduction, agenda (chairs, 2')

BL doing introductions

BL: Still planning to start with a tutorial. Still fine with that?
CA: Yes, it's relevant for some of us, and it'll make a great recording.

BL: We have Orie as new Responsible AD.
OS: Hello. Reach out to me, or often found on The Slack Instance.
Looking forward to work with you. Also CBOR enthusiast, so expect to see
me w/o AD hat as well.

Tutorial block: "Using CBOR in specifications", 30 minutes

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-cbor-edn-cddl-yang-packed-00.pdf

EDN

CB presenting.
(best reached on Telegram and Zulip, no S.)

CB: We'll cover mostly EDN (diagnostic notation) and CDDL
(language/grammar).
CB (p2): Overview of CBOR and EDN & CDDL.
CB (p3-5): Concepts and examples of EDN, in comparison with JSON

AJS (chat): Interested in CSV draft.
OS (chat): Are text strings always quoted? CA: Yes, no bare words

CB (p6): -cbor-ed-literals is with the IESG soon and covers all of the
above

e-ref, draft-numbers

CB (p7): There's yet another recent draft to better use placeholders in
examples, when still-to-be-registered abbreviations have to be used
whlie developing a draft. This uses the new extension 'e' for importing
from a CDDL definition/file into an example in diagnostic notation.
CB (p8-9): Examples from draft-ietf-ace-oscore-gm-admin, where labels
are numbers (so text labels would break CI, and without CI, errors).

OS (no hat): dash-vs-underscore, snake-case-vs-kebap-case -- is that
significant?
CB: Yes. CDDL inherited from ABNF. ABNF is kebap-case. But users come
from languages that don't have skewers, so both is allowed and used.
Comes from a spec that has been written in CDDL but was migrated from a
spec that did not start with CDDL.
OS: Guidance for authors for consistency?
CB: Different approaches collide here…

CB (continuing, p9): cddlc evaluates environment.
CB (p10-11): There's another draft -cbor-draft-numbers trying to
establish a convention (and suggesting CPA instead of TBD as
placeholder)

(people on chat bantering around style guides, linter and indentation)

CB (p12): Example from RATS. This covers a different extension ref'' for
importing not from a CDDL definition/file but from another diagnostic
notation example/file.

CB: Please try and comment on the e-ref and draft-numbers; currently
individual drafts.

cddl-modules and more-control

CB (p13): Over to CDDL. Three related WG documents: update to CDDL
(-update-8610-grammar), more control operators (-cddl-more-control), and
-cddl-modules.
CB (p14): On -cddl-more-control, it allows for expressing text that
actually includes data.
CB (p14): Actual use, eg. base64 in RATS, allowing CBOR and JSON being
carried around.
CB: What's the status on this?
CA: We had the WG Last Call but no feedback. All, have a look and give a
feedback.
CB: Should ping RATS/FFT.

AJS: This example with .printf reminds of an example of an application
that ...?
CB: Yes, except the one that I excluded.

LL: .cbordet is CDE?
CB: No. CDE defines its own control operator.
LL: Isn't CDE the only deterministic thing in RFC 8949?
CB: 8849 gives you more latitude than CDE does. This is somewhere in the
cloud spanned by 8949, while CDE defines a subset of that. Control
operators are cheap...
LL: But it's also a confusing topic for people. I'd be a fan of
minimizing this, maybe even not having .cbordet in favor of .cde
CB: Please write as WGLC comment
LL: Sure.
CB: Unaware of any draft using this at the moment, so it would be safe
to change it.

CB (p15): -cddl-modules defines the concept of directives and specifies
two of them (include and import).
CB (p16): Example from RFC 9052. Still have a bug to fix related to
sockets and deciding on a single way to handle them.
CB (p17-23): Also possible to define namespace by the keyword "as".
Local aliases are also possible to define for avoiding repetitions.
CB: Note it's not a preprocessor in the C sense; it understands the
language.
CB (p21): "import" takes only what you need, while "include" takes
everything
CB (p23): by path, it's possible to indicate RFCs as content source. To
be considered are IANA material (unstable XML), possibly drafts, maybe
more like Github repos. I'd like input.

(chat: comparing with other programming language imports)

AJS: Allowing local paths and HTTP URIs is wonderfully convenient and
awesome, but also brings up traumatizing memories for some. Not sure
it's in the cards. Possibe/interest?
CB: This is now in the implementation, with a big blinking light on file
access. We have to define it better, but so far we can live with
importating from RFCs referred to by number.
AJS: I was worried of this and XML users would refuse that part. The
import/include dichotomy is confusing for many.
AJS: (comapring to programming languages)
CB: CDDL is quite different from programming languages. Due to
sea-of-rules it is different from their imports. Please do send in
pieces of experience.

BM (one of the authors): I prefer the pythonic approach (import *) for
clarity, this eliminates confusion. Disagreement among authors.
CB: So we'd still have the two directives, just with different syntax.
BM: Yes. import * from COSE is an include but makes the semantics
clear, and only 1 directive.
CB: Sounds good, it's just a syntax change, and the two directives still
keep the different intended semantics.
(chat: MCR, CA don't object, support the propsed change)
LL: I understand why you want two directives. Want to know whether you
have excess rules.
CB: That's also supported by live experience from users. Also got
offline input from TF.

CB, concluding: Have something like MVP for module structure -- enough
on todo list for some more months, also for IANA. Scaping works fine but
is not that useful if they change everything.

Discussion block, 60 minutes

Agenda bashing and current documents (5', chairs)

• (on notes but missed taking it up) shepherd buffet: more-control

CA: Recapping the status of documents in the WG through the Chairs'
slides.

yang-standin (25', CB)

Goal: Discuss with wider audience, especially from network management
and operations audience

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-cbor-edn-cddl-yang-packed-00.pdf

CB presenting (draft has significant input from Maria)

CB (p24): We can represent YANG efficiently now, but some data type were
specified that require dedicate handling now. That's date/time and IP
address/prefix.
CB: Caused by XML legacy, encoded in YANG base type which is text.
CB (p25): We have CBOR tags that we can use, but there's the open point
on the deterministic representation of this kind of information. ("No
time zone associated" has no preferred text form, would have to pick
one.) Needs write-up that is understandable in YANG context.
CB (p26): One main remaining thing is how to announce the capabilities.
YANG has the brenches with text strings or SIDs as identifiers, based on
the used media-type. But this comes in later, so have to "sneak this
in", which is difficult to get done reliably, implentations may be able
to use stand-ins or not, or rely on them.

MCR: I inadvertedly encoded with the better encodings, Esko said "that's
a good idea, I fixed my code", that was how this started.
MCR: core-sid etc has sailed, constrained-voucher has not. But ANIMA
could reference this if we publish this year.
CB: You can use a media type, great situation there.
MCR: We don't want to delay and want to be done by the end of April.
MCR: For a lot of things it will be easy, say "It's YANG plus
this-other-thing". Documents can state to use this.
MCR: And yes, do it here b/c we did YANG-CBOR in CoRE b/c we didn't have
CBOR group.
CB: Can't remember.
MCR: Here we have the expertise for the encoding, but we need the YANG
people too.
CB: Joint WGLCs.
MCR: For classical network management, they can wonder about what the
right thing to do on a server is and so on, but that's not a problem.
They want to be able to quickly send the most constrained thing; this is
supposed to produce such small things to be very convenient.
MCR: Do it here, do it quickly.

JH: (from efficient streaming telemetry context) It's hard to get netmod
to take up work, but for a piece of this that's the right place. Need
way to decorate YANG modules that this-and-that CBOR tag is part of the
machinery. There are other nodes that can also use more efficient
rendering. Pattern to talk about that kind of things. Similar for enums
and identites.
CB: We already have some identity mechanisms in YANG CBOR. Good to have
it here too.
CB: We should not be in a position where we wait for YANG, so we can
solve problems expediently on our own. Let's discuss further.

MM: YANG has deviations, augmentations and modules. What we dicussed in
CZNIC is to include augmentations to have CBOR module that says which
tag stands in for which thing, and in our module, would augment the IP
and date types (or include the canonical augmentations, or include
augmentations for our internal types).
CB: What are we optimizing? The integration in YANG or the mid-long term
time-to-market? Probably both, but we have to balance the requirements.
I'd prefer to privilege the integration into the YANG universe.
CB: Devote interim in April?
MM: Extension is the right word, and we can just go ahead and define it.
Then we define how to use CBOR for it, and people can use it. That
reduces time to market, and it's a good way for integrating in YANG
anyway.
JH: Augmentation wiht an extension is easiest path. Challenge:
Augmentation is easy to do one thing at a time. Tricky are fundmaental
data types (date etc are typedefs in the language). Language doesn't
have plumbing for augmenting language types. Can do it fast on CBOR side
if external tool does it, so that rule is easy to break.
CB: Hope to not have to touch every YANG module that wants to use it,
should be a global thing where entire server is switched to stand-ins,
not module-by-module when you'd need to keep supporting both.
MM: +1 to JH, it's good to push NETMOD to update YANG the right way.
CB: Hoping not to push NETMOD, but ok.

packed (15', CB)

Goal: Make state known more widely, decide next steps

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-cbor-edn-cddl-yang-packed-00.pdf

CB presenting

CB (p27): overall goal of addressing redundancy. Packet CBOR applies
compression ad the data model level, and is usable in packed form.
CB: Calling it "packed" to not confuse it with byte-wise "compression"
CB (p28): This draft has been around for a long while, it's pretty
stable now.
CB: Least stable (only basic battery included) is table building. Expect
applications to come up with additional ways.

CB (p29): Open issue about error representation. (Do we have to?). Have
PoC implementations.
MM: I can do partially the same thing by designing the model itself the
right way -- sending a cache ahead, having packing in the model itself.
What is preferred?
CB: Common set of referencing tag has advantages and disadvantages.
Being there is an advantage, but needs coordination. Own tags are not as
efficient. For the most likely cases it's good to have common tags, b/c
they get much from the common code space.

CB: 4 drafts are using this, so better to not delay this document too
much.

packed-by-reference (10', CA as author)

Goal: Propose for adoption

Presented slides:
https://datatracker.ietf.org/meeting/119/materials/slides-119-cbor-packed-cbor-table-set-up-by-reference-00.pdf

CA presenting

CA (p2): Packed CBOR would also be used in CoRAL, which not only acts as
alternative to link-format (RFC 6690), but is also intended to describe
a resource.
CA (p3): That level of expressiveness requires a non-trivial dictionary,
which makes Packed CBOR particularly convenient.
CA (p3-4): Example on a descriptive link
CA (p5): In a CoRAL application, there may be extensions such that they
go beyond what expected from the signaled media-type.
CA (p6): This can be addressed by instructing a shift of the entries in
the used reference tables, that then can be used the old way.
CA (p7): You can also further optimize to avoid long names
CA (p8): Its feature description should be completed now, I'm working on
an implementation. Is the WG interested on this?

CB: On setting up the application-related tables, do they happen here or
in CoRE?
CA: Not simply application-oriented and for CoRAL. It's a general way to
avoid large/inconvenient table setups.
CB: Ok, then I think it should be done here.
BL: We'll follow-up on the mailing list and decide what to do.

Flex time / AOB, 5 minutes

CA: Interim meetings will continue, with the usual cadence, alternating
with those of the CoRE WG.