CA: Welcome and note well. Thanks to Barry, welcome to Francesca as new upcoming AD.
CB: Possibly two more slides to share compared to the original agenda.
CA: Passed WGLC; I've completed the shepherd-write up, now on the IESG. Missing one reply to IPR declaration, no actual complications are expected.
CB: Defines control operators and ABNF as a CDDL model. Missing feedback from implementations, so I generated one to play with. Found out that ABNF is indendation hostile, while indentation is desirable in CDDL. Can perhaps ABNF being fixed? But it would take too long, so rather add something in the control operator draft, i.e. "dedenting cat" (.det). This allows writing the examples previously in the document but not compiled by the implementation.
CB: The whole draft is implented in the CDDL tool, but half of it in the Andrew tool. Version -03 would be fine for pre-WGLC reviews or just proceed with (a first) WGLC.
CA: How many have read/implemented an earlier version?
--- 2 people raising hand ---
CA: Would like to see more feedback on the list, but I don't see complaining either. Unless issues arise, this seems good to proceed.
CB: Pre-WGLC reviews or WGLC?
FP: If no issues arise, we can start WGLC, which will bring reviews.
CB: Now missing details on the table setup. Raised issue on adding circumfix packing (we can later add tags for this). Need for more reported experience; an old implementation has to be adapted, more implementations than mine would be needed.
CA: Other than SUIT, who has done something different? Anything putting a timeline on this document?
CB: My POV is that there's a lot of JSON-based protocols that can convert to CBOR and gain improvements if we have cbor-packed available. A strong use case would come up soon anyway.
HB: True, that's the benefit. Other string-based protocols can use a string repeated over and over, and this addresses the issue. You don't need particular proof that this makes sense.
CA: (not-as-chair): It may seem like you are recreating the original JSON by using the CBOR packing doing its magic. Just to be aware of this.
BM: I really wished this would have been available when SUIT did something of its own. A potential future version of SUIT would really benefit of this being out and stable.
CB: On your possible issue, maybe this is what we want and it depends on the possibly constrained nature of your environment. If CBOR is good enough, why going for a different data model?
CA: Who is going to implement this and provide reviews?
Michael Richardson, Henk Birkholz, Russ Housley, Brendan Moran, Alexey Melnikov (on Jabber): will review (also Kio Smallwood and John Mattsson, time permitting)
FP: Who plans to implement?
CB: I do certainly, we need more.
MCR: This was also presented at previous interim meetings. Original use case was unit test systems, comparing to PEM files.
MCR: In your source code you may want to know what is what, and what is going to be transmitted. CBOR sequence was suggested. The document follows that suggestion now.
MCR: Now you start with a CBOR tag 55799, followed by an allocated tag (first come first served), followed by the CBOR content. The alternative would be to have the CBOR content as a sequence, which requires wrapping the sequence into a byte string to make it taggable.
MCR: Implemented, with result as expected. Wish to just go for a simple BCP.
CA: WG early allocation would be a starting point that we should possibly do more often.
CB: We can't do it here since it needs IETF review, but this is FCFS, it's just about requesting allocation.
CA: Anything to be really decided between the two alternatives?
MCR: People wanted both.
MCR: CBOR encoding of IPv4 and IPv6 addresses, using a tag. It's currently possible with tags 260 and 261, where it seems a few things were not flexible enough.
MCR: This proposes a dedicated CBOR tag for IPv6, applied to a CBOR byte string or to a CBOR array where the prefix size is also indicated.
MCR: A separate, analogous CBOR tag is defined for IPv4.
MCR: Open point on enabling arrys of addresses or prefixes. If someone needs it, it can be done. Would like to have an early allocation of tag values. Is it justified to go for 1+1 byte tags?
CB: On the early allocation, you can't have it on 1+1 tags, they don't require IETF review. You have to check with the Designated Expert, who check with the WG, and if it's fine it's done.
CB: eliding trailing zeros is a lot of work for implementors, with little return. I suggest to do it for prefixes only.
MCR: it happened to be feasible in my receiver implementation. It's anyway ok for encoders to not drop trailing zeros.
CB: Thinking of interop, this is the kind of thing where problems happen. Not sure that "it is just going to be fine".
CA (not-as-chair): about the existing tag 260, do you plan to add some compatibility statement, to have the new tag interop to the old one? Or is it up to the application?
MCR: One defining a CBOR protocol based on this should say what exact tags to use, with them not being interchangeable.
CB: That's the job of the notable-tag document, as to how tags work or don't work together. I'd like to keep things crisp to make implementors' life easier.
CA: Sounds good. Who plans to implement or review this?
Raised hands: Carsten Bormann and Alexey Melnikov
CB: It has been around for a while and it is in active use. Now there are additional requirements, e.g. time scale indication and clock quality/uncertainty/guarantee. Also defined a representation for duration and period (no implementation experience yet).
CB: Not urgent, but some protocols would benefit from it. It would be possible to complete this in 2021.
HB: I'm working on things needing this, and I see others just asking themselves "how do I express a timestamp here?"
CA: Interest for adoption?
11 raised hands
CA: We'll confirm on the list, looks promising to become a WG document.
CA: It wasn't an IETF activity, but it's of interest for discussing here.
KS: The ordered of keys in the map is important, especially for comparison of maps that assume a deterministic encoding. Now proposing a CBOR tag 279 so that it is possible to signal the intend on key ordering. Duplicate keys are not supported (otherwise it has the same semantics as a map).
MCR (on jabber): 1+1 byte tag seems fine.
CB: Maybe it's finally about time to do this.
Jeffrey Yasskin: It seems a useful thing to have.
CB: also support for 1+1 byte tag.
CA: Next items are left for the interim meetings.
FP: Yes, we have interim meetings scheduled; was nice to work with you, I'll be around as AD.