Minutes interim-2023-cbor-16: Wed 14:00
minutes-interim-2023-cbor-16-202310181400-00

CBOR working group conference call, 2023-10-18
Meetecho:
https://meetings.conf.meetecho.com/interim/?short=3a464868-63f0-427d-807e-cccdb30e83cd

WG documents status and issues

draft-ietf-cbor-

• time-tag (CB)

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-16/materials/slides-interim-2023-cbor-16-sessa-time-tag-edn-00.pdf

CB: In IESG processing, submitted -10 based on AD review, ongoing IETF
Last Call ending in 3 days, then telechat.
CB: Directorate reviews coming in; Thomas' artart review is merged,
Qin's iotdir review has an open PR. May want to do -11 before, or after,
depending on when things come in.
CB: The SEDATE document (a dependency of this) is on tomorrow's
telechat.

• edn-literals (CB)

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-16/materials/slides-interim-2023-cbor-16-sessa-time-tag-edn-00.pdf

CB (p3): Reminder of differences from CDDL.
CB (p4): Could now be called EDN maintenance and extensions, may still
change title.
CB (p5): Processed feedback, released v -05, now ready for WGLC.
CB (p6): Changes in v -05 (largely based on input from CA).
CB (p6): ellipsis was discussed in interim ~1y ago, but never turned
into text until now. Also supported Appendix G.4 of RFC 9164, and
lowercase/uppercase of IP addresses (though supporting prefixes but not
netmasks).
CB: This should be ready for WGLC.
BL: I'd start it, maybe we can give time until after EITF 118 to not
overload people.
CA: It's ok to start now.
BL: Ok, then it can end after IETF 118.
CB: Or it ends before the meeting, so that we can discuss the results.
BL: Ok for that. So it starts today and ends on the Monday of the IETF
week.
CB: Sounds good.

• update-8610-grammar (no slides)

CB presenting

CB: I confirm it's ready for WGLC, we'd just want to have it in parallel
with that of -edn-literals.
BL: Ok, both will start then.

CDDL 2.0

(see above)

CBOR use in IETF and other SDOs

Name compression in application/cbor+dns (ML)

Presented slides:
https://datatracker.ietf.org/meeting/interim-2023-cbor-16/materials/slides-interim-2023-cbor-16-sessa-cbor-of-dns-messages-evaluation-of-name-compression-00.pdf

ML presenting

ML: Follow-up from previous interim meeting
ML (p3): Graphs and results from last time on compression ratio and byte
savings. Do we want name compression for the name format? It seemed so
and I worked on that.
ML (p7-9): Two options: wire-format stile, or compact CBOR-based. The
first option uses text strings or tagged unsigned integer. DNS uses
offsets in message, but that is hard to implement; using i-th tstr
instead. Example on p9.

CB: Tag 25 is called "string referencing" and gets the replaced by the
previously referred string. Your counting goes forward, while that tag's
goes backward. The functionality is the same, you may want to look at
that and the differences.
ML: I think going forward is easier. Semantics are also a bit different.
You don't take only strings, but also whatever comes after the name.
CB: You take the rest of the array.
ML: Only the rest until it's not part of the name anymore. (Eg. ttl not
included.)
CB: That's good material for a paper.

CB: How do we save things here? The table building is implicit and
relying on an algorithm. This saves expressing the table explicitly as
an array, and the first occurrence of the table.
ML: We'll come back to this when going for cbor-(packed)-light, you're
getting ahead.
CB: You can measure, but also understand what is going on. Overhead of
using explicitly set up tables can be very small once they are set up.

ML (p10): This first approach is very easy to implement (done both in C
and Python).

ML (p11): The second approach is based on Packed CBOR, using an array
rather than a dictionary as in a similar earlier proposal.
CA: This is the tag setup as normally in packed cbor. Is the tag setup
implicit? Would this result in 2 byte overhead?
ML: It's implied, and behaves like tag 113

ML (p13-24): repeated experiments, producing the same results. The gain
is very small for queries. Much better gain for responses, and only a
few of those are not further possible to compress. Summary of takeaways
on p24.
ML (p25): The advantage introduced by the possible flag rotation is not
worth the complexity and risk of confusion, so I don't think we should
do it.

CA: Re the compression of responses without requests. Better to tap into
the request dictionary at the beginning already? It still repeats the
names once.
ML: It depends if the request is present of not, and if it possible to
associate with our state for omitting it. You have to get the name from
somewhere else if you don't have it already.
CA: So one can send a response without including the long name.
ML: Yes.
CA: So the resolver can make the responses small enough (i.e. not have
any long names in there) that there is no benefit to be gained from
setting up the tables with knowledge of the request.
ML: Yes.

CB: This is a case with different perspectives leading to different
opinions. The first approach seems more efficient than the approach
based on CBOR packed. However, CBOR packed is a generic component. From
an ecosystem point of view, how can we make it more powerful? Using the
packing helps, as it is usable also for other data. Important to
understand the impact of what is chosen to be used. Good to see side by
side the results of the two packing approaches.
ML: Will look into that and hopefully present it in Prague.

CB: Is it possible to do something like implicit table setup with CBOR
packed?
CA (on chat): +1
CB: Good that both topics are converging to the agenda for IETF 118.
ML: We'll find a way ... am already spread thin for hackathon.

ML: We plan a version -05 of the draft before the cut-off, not including
this yet, but including also lessons learned from implementing.

IETF 118 (Prague) agenda

Finalize agenda for our session at IETF 118
Please add proposed items here now.

BL: Clearly have packed and DNS in there.
CB: If WGLCs are finished by then, could discuss results.
BL: Yes, the in-progress documents and then those two.

CA: Any progress/news around the various dCBORs?
CB: Not much work done in last couple of weeks; not sure there'll be
progress in next couple weeks, maybe more on interim.
BL: A few minutes on it will help and remind that it's moving on. Maybe
5' thing.
CB: Not going to stay 5'. Just need to be sure to not use dCBOR but
"deterministic encoding profiles".

draft-ietf-cbor-packed (CB)

draft-lenders-dns-cbor (ML)

Dates for interim calls through IETF 119

BL: Proposed dates, coordinated with CORE:

29 Nov, 13 Dec, 10 Jan, 24 Jan, 7 Feb, 21 Feb, 6 Mar
It's the same cadence, continuing as we were.

BL: Do we need to do 6 Mar, as it's only 1.5 weeks before the meeting?
CB: Think it's often useful to have one after the draft cut-off. Can
still cancel.
BL: OK.

AOB

Note taking: Marco Tiloca, Christian Amsüss