CBOR session at IETF 118 (Tuesday, November 7, 2023, at 15:30)

Agenda

• Intro and agenda review (chairs, 2')

• Documents that are finishing up (chairs, 5'?)

  • IETF evaluation for time-tag
  • WGLC for edn-literals and cbor-update

• Other in-progress documents

  • draft-ietf-cbor-packed (CB, 15'?)
  • draft-lenders-dns-cbor (ML, 10'?)
  • Brief mention of deterministic encoding profiles (chair
    summary?, 20' based on list disussions?)

• Dates for interim calls through IETF 119

  • Proposed dates, coordinated with CORE:
    29 Nov, 13 Dec, 10 Jan, 24 Jan, 7 Feb, 21 Feb, 6 Mar
    Same cadence, continuing as we were.

• AOB

Agenda additions

• JSON-NTV from dispatch? (chairs' pointer, 1')

Intro and agenda review

CA doing introductions

CA: Any agenda bashing?

CA: There is a thread on the mailing list about the discussion in
DISPATCH on JSON-NTV

DE: The -bis for RFC 7042, draft-ietf-intarea-rfc7042bis-11 (currently
in RFC editor queue), has CBOR tag registrations for MAC addresses
[post-meeting addition: tag 48] and OUIs [post-meeting addition: tag
1048]

Documents that are finishing up

CA: time-tag is in IESG evaluation; a DISCUSS is resolved
FP: I just have to give a quick look, then press the button and it's
done
[post-meeting addition: Document was approved during the meeting
https://mailarchive.ietf.org/arch/msg/cbor/9YALc9UT3WBgNP91-zlB-7mPbys]

CA: Had WGLC on edn-literals and cbor-update, finished yesterday. No
feedback on the mailing list. I'd like to extend the WGLC for one more
week. WG, please comment.
CB: If it helps, I have slides about that.
CA: Yes, that helps.

edn-literals and -update-cddl-grammar

CB presenting

CB (p2): CBOR is a representation format, not a language. Then we have
two languages: the extended diagnostic notation (EDN, used for examples)
and CDDL (for specification/validation).
CB (p3-4): The two related drafts -edn-literals and -update-8610-grammar
ended WGLC yesterday. We received a lot of feedback on the former before
the WGLC, so not surprised that no more comments came, but please have
one more look. The latter mostly focused on addressing errata against
RFC 8610.
CB (p5): People often use text strings in early EDN examples, even
though they actually mean a placeholder for a later, to-be-registered
integer (it came up again also in COSE earlier today). This might be
also addressed in a further application-identifier registration to EDN,
once we have a Designated Expert to take care of the newly created
registry.

draft-ietf-cbor-packed

CB presenting

CB (p6): Recap of history and rationale, wanted an in-place used of
packed CBOR data items. That builds on two separate elements: reference
tables to build first, and then refer the right table entries from a
"rump".
CB (p7): The part on references set is pretty much ready.
CB (p8): The table building in itself is application specific, with
different possible methods envisioned. Some simple setups are provided
as "batteries included".
CB (p9): Tables can be built implicitly, starting from the rump that
needs to build the table. The building can also be incremental, to allow
immediate use after the primitive.
CB (p10): Next steps are getting more feedback from benchmarks (e.g.,
DNS in CBOR) and implementors. Eventually, we have declare this done and
have WGLC on what we have, somewhere before the next IETF meeting.

CA (not as Chair): on the trouble with maps, if the application requires
using deterministic encoding, can one rely on deserialization sequence?

CB: Sounds good to me.
(Further "sounds good" from the room)

→ Confirm time box?

draft-lenders-dns-cbor

ML presenting

ML (p2-3): motivation backed by results on message size when using DNS
over CoAP.
ML (p4): work about encoding DNS messages in CBOR to achieve concise
encoding, also with some optimizations. CBOR-packed was also considered.

ML (p5): Some DNS fields can be omitted altogether. This is possible
both on query requests and on responses.
ML (p6): Summary of changes since IETF 117 and version -03: more on
representation and format description, and on implementation status;
made simplifications and clean-up.
ML (p7): Example of achieved gain using CBOR.
ML (p9): Implementation activities.
ML (p10): results on compression ratio and byte savings. Compression of
the name format was clearly needed.
ML (p11): On compressing names: none, or bespoke DNS approach, or
CBOR-based approach.
ML (p12-14): Approaches and examples for compressing names.
ML (p14): The first approach splits the domain name into different
components, building on what is being defined in draft-ietf-core-href.
This looks like a variant of Packed-CBOR.
ML (p15): The second approach is a lighter version of a proposal by
Lemogue et al., using only names into account for table building.
ML (p16): Showing results of gain due to compression. The dataset was
limited, so more research is needed.
ML (p17): The first approach is concise, simple, and familiar. The
second approach is consistent and efficient.
ML (p18): Question to the WG: which way should we take? Or should we
have the implicit table building for packed-CBOR in general?

CB: Thanks, that's the work that we needed to make a decision.
CB: On slide 14 (43rd slide) "Idea 1: Reference Name Components", we
would need slicing references. We would need to insert an array into
something that is becoming an array, basically what is happening here.
Maybe it's good to add this slicing reference to Packed CBOR in the
first place.
CA: Do you mean that by slightly extending Packed CBOR, then what is on
the slide can be packed?
CB: Yes.

CB: The CDF graphs are based on a corpus; as always, the choices going
into that could be debated. Typical issue: From some lab implementation
-- it's million packets all from one source. So the numbers are not
perfectly valid. Anyone got more data? Contact us.

DE: DNS labels can contain periods.
ML: That's why CA proposed to rely on the CBOR format for names.

ED: About the DNS request, can I have an example when the query count is
greater than 1? I'm not sure if it fits that format. Although the
support for it is debatable, there are implementations that use it.
ML: Followed it on DNSOP; need to think, not sure of use case.
ED: The use case was pre-decided in a side-meeting yesterday, and there
were better ways to do it. It was about requesting two records for the
same name, but it's better to use EDNS options and rely on better
properties also for legacy receivers.
CA: We take this offline in the interest of time.

deterministic encoding profiles

CA, summarizing traffic on the mailing list

CA (p7): This started with requirements from the Gordian project. Now we
have on the table a common deterministic profile (CDE) as related to
dCBOR on top of it and providing numeric reduction, removing a few
things like "undefined" and other simple values, and half negative
integers. A few controversial open points remain. Hope that CB and WMN
will collaborate to converge.

CB: dCBOR is perfect for that kind of applications, but not for others.
But the basic model can instead do something different and more general.

WMN: CBOR is fine as-in on representing things. dCBOR is a bit different
and focused on a specific problem space. Agree with Carsten dCBOR is a
profile on top of CDE on top of CBOR, and that we should merge the two
dCBOR documents. I'd like dCBOR on the Standards Track.

CB (p12): Deterministic Encoding comes already from RFC 8949, but some
things are left to the application. This is not trivial to take into
account for writers of encoders/decoders. Such clarifications now come
from CDE as a Common Deterministic Encoding profile, on top of which one
can build Application Profiles such as dCBOR. I don't expect many
Application Profiles to come up as the latitude to operate with is not
that much.
CB (p13): I propose to be quick in adopting the CDE document (now as
BCP, but it can be a Standards Track just as well). Already had some
discussion with Wolf on the merging with the dCBOR document. We can also
get rid of the extensibility aspect, which is not for dCBOR. We should
be able to do this next month.
CB: Please have a look to the CDE document, especially for deciding
between BCP and Standards Track.

CA: For all in the room, would you support adopting the CDE document?
Show of hands: yes: 16; no: 0; participants: 23

CA: We'll start a WG adoption call on the mailing list.

Dates for interim calls through IETF 119

CA: We had successful interim meetings, alternating with the CoRE WG.

• Dates for the next series of interim meetings, coordinated with CORE
  WG:
  • 29 Nov, 13 Dec, 10 Jan, 24 Jan, 7 Feb, 21 Feb, 6 Mar
  • Same cadence, continuing as we were.

AOB

(chair action note-to-self: make sure downstream documents defining tags
are linked in datatracker by explicit inclusion as documents of interest
to the WG)