Agenda items:
CA: Reviews are needed, also to ease the shepherding. Volunteers?
CB: Henk has looked at the document, he can do that in a week.
MCR: I can review
CB: 3 things together: ABNF; infrastructure for that also with .plus; feature extension/control which is useful in the SDF world.
CA: any tooling using it already?
CB: all is implemented in classical CDDL tool. Andrew Wise has a partial implementation, no time recently to complete it. Adding ABNF takes a lot of time if the indrastructure is missing in your platform.
CA: I started to play around with Carsten’s implementation.
CB: Wrote the implementation 4 years ago. Problem was to efficiently represent WoT things descriptions, which used to be chatty. Now back on it, the decompressor should be completed now (to be validated); the compressor is simple-minded, works well on shared items, it’s simple about prefix compression. The implementation can be extended later on to allow the application to better control how the compression works.
CA: this particular application is very recent, this requires some usage by the ones involved. Easy now to take our examples and test this.
Russ Housley: it could have been used in the SUIT WG
CA: Anything you can use in the existing compressor?
Russ Housley: Don’t think so, there we ended up with a different solution
CB: If you go for something dedicated in the application it becomes difficult to use something like this.
CA: More eyes on the doc are welcome, I also plan to
CB: the actual packed format is important and will likely remain stable for a long while; the other part with the table might have frequent changes.
CA: is the document well defining the scope of the tables?
CB: the tables use a hierarchical mechanism (which I think is going to be the normal one); there can be side effects on their definitions from acting on something else related to them.
CA: this is using the linear approach from CBOR packed. This is coming from request for tag allocations (data with repeated entries in existing groups). Think of a SenML document with a same structure repeated throughout the records. Contacts with Kris recently?
CB: Ongoing on&off discussion, took time to understand the problem. There’s RFC 8742 no homogeneous arrays, possibly to relate to homogeneous collection of rows. That made the proposal suboptimal, but it was a misunderstanding.
CB: It seems it’s not only about compression here but also about a semantic component. Maybe the semantics can be completely derived from the record definition. This may shape tag definition in the long run. I’d like to come to a little library with information-model level, with tags telling how to represent a CBOR data model, given a record as starting point.
CA: How does it relate to using enums?
CB: Column names are useful if you don’t have record definition pre-defined. Sending definition+names is useful to avoid schema.
MCR: You can add a lot to every CBOR string that may not survive every round tripping. Question is if the data (not the metadata) survive the round tripping, and it deserves considerations anyway (e.g. loss of precision but without loss of actual data).
CB: It’s not just a bilateral relation between one sender and one receiver; data and metadata can end up in different places.
MCR: I’m thinking of graphics or statistical programs that don’t have particular knowledge but still make some use of the metadata.
CB: Another aspect is the linear aspect; the CSV-like proposal brings structure and the data in the data item. We need to define partial ordering if we want to support the lineary way, so that safe data usage can be ensured for users.
CB: RFC 8949 does not say what is recommended to do with the linear approach; this kind of recommendation should go in some document. Quesion is where.
CA: Something in scope for LWIG? Or to just take here?
CB: Not sure LWIG will be around for a long time, but maybe a bit out of scope for them.
CB: CBOR group does two things, “include batteries” and maintain CDDL;
CA: It would be publishing guidance on how taking care of extensions.
CA: Any usage to report?
CB: SenML, there we had something like this. It hacks sequences of non homogeneous records, but they come in small numbers. So it fits SenML well.
CA: Even the single-record type category.
CB: We may have one base record and then all the other ones. It’s good to think of SenML in relation to this and see what happens.
CA: Who has selection of SenML files?
CB: Ari should have a good selection of SenML files to use. I can ask him.
Network addresses
MCR: ongoing discussion on indicating a full IPv6 address plus a prefix to describe the network. Not sure if it’s useful. Carsten suggested to use a syntax. What does the WG think?
CB: This came as an input, an interface configuration with address + number of bits is common as an application.
MCR: “interface configuration” is good wording. That brings other stuffs, like default route, maybe link server. Maybe other data have to be communicated and we would be describing high level concepts. We can treat all as a prefix.
CB: But we would lose the distinction.
MCR: I prefer to not solve the problem here, and leave it to address by someone else with another tag. But no strong opinion.
CA: if the other information was in some other format, do they have to reinvent things?
MCR: they would have a prefix to take advantage of. It feels like a map with keys.
CB: it’s useful to have tags for this.
Russ Housley: Thought experiment: If someone wanted to write a description of address blocks and AS numbers. Would they have all elements?
MCR: As in an RPKI? Yes. They would not care about trailing bits. Address of RPKI server would be just an address. AS numbers: have no tags, but pro’ly key in a map, with values several prefixes.
Russ Housley: no, but you’re ok if you can tell apart AS numbers and AS number ranges.
MCR: on the IP address side it should just be complete. I’ll check again by email, and suggest how this could be done later on, but we shouldn’t do it in here I think.
CB: I don’t agree, it seems people need it; I also didn’t think of this initially. I wouldn’t wait for the problem to come hoping for it not to come.
MCR: I would just say I’m on the fence on this, asking for argument why it ought be done now.
CB: Maybe calling it “interface configuration” was confusing.
MCR: is it useful for other than a interface configuration? I’ll ask it too.
CB: I’m also thinking of a possible better term. Long term is address+prefix the address is in, but not sure about a short term.
CA: We can bring it to the list, no need to decide now.
CB: No reason anyway to stop from using it now.
CA: Like in Yang, does it make sense to say what we have here is also useful in different contexts?
CB: Due to Yang+CBOR, there is a defined way to represent this. The existing specs are not describing data on the wire but data address. Some “transfering” is needed to have it ready for a protocol. Will be good to write an informational document binding with CBOR information.
CA: Sounds good.
Attendance: