CBOR support

[marenamat]

Hello!

Are you planning tu support CBOR? Or, if I went for implementing it, could you please give me a little guidance what to implement? I'd naturally look into how JSON or XML import/export is implemented and write a similar code for CBOR. Are there any caveats which I should watch out for?

Thank you for all your help.
Maria

[michalvasko]

No, we have no plans for supporting CBOR and instead we have our own LYB binary format. We have decided this way mainly because of the CBOR requirement for a global mapping file of schema nodes to integers (but LYB has its problems as well).

So, my advice would be to carefully think about the design with regard to the schema node identifiers. Specifically, how to handle modules with no found mapping. You could refuse to print such a module but one often works with non-standardized modules, from drafts or vendors, so it does not seem like an acceptable solution. I would provide more input once you have basic use-cases working and a PR in libyang created.

[graf3net]

We are working with the IETF community on YANG-Push publisher implementations supporting CBOR named identifiers (https://datatracker.ietf.org/doc/html/rfc9254#section-3.3) and working with https://github.com/NetGauze/NetGauze on a YANG-Push receiver implementation.

We were wondering wherever your comment was referring to CBOR SID (https://datatracker.ietf.org/doc/html/rfc9254#section-3.2) management and wherever you would accept a contribution for CBOR named identifiers. We are attending IETF 122/-124 hackathon.

[michalvasko]

Yes, that is the SID I referred to, global unique numbers for every schema node for every published YANG module. As I said, we would accept CBOR implementation but it would have to be of reasonable quality, which code made on hackathons never is. So if you are willing to then make it up to standard, we will gladly accept the implementation.

I would also appreciate some feedback and information about CBOR use because it really seemed like maintaining the SID database would be too difficult. Is it actually being used? Are there no problems with adding new modules and compatibility between various projects?

[graf3net]

There are multiple major network vendor implementations on YANG-Push publisher CBOR named identifiers in progress. We will have the first test implementations at IETF 122. They are expected to be production ready, general available in early/mid 2026. More details here (slide 18): https://datatracker.ietf.org/meeting/interim-2025-nmop-02/materials/slides-interim-2025-nmop-02-sessa-an-architecture-for-yang-push-to-message-broker-integration-00.

The code contribution for libyang I was referring to would be production ready quality. What we like to understand is wherever the code contribution would be merged if quality standards are met or not.

The slide deck shared should give details on use cases. The main benefit on binary encoding will be not on saving bytes on the wire but on storing notifications in binary on the message broker. Here we see a big difference today by using AVRO binary encoding vs. AVRO in JSON.

CBOR SID appears to be to costly to maintain for the reasons you described.

Need more information?

[michalvasko]

More details here (slide 18):

Not sure if you are aware of it, but our netopeer2 (open-source) should fully support YANG Push in its current specification. But we are aware of this effort of a simplified YANg Push specification and would like to support it in future.

The code contribution for libyang I was referring to would be production ready quality. What we like to understand is wherever the code contribution would be merged if quality standards are met or not.

Sounds good then.

The main benefit on binary encoding will be not on saving bytes on the wire but on storing notifications in binary on the message broker.

What is AVRO format? What is its connection to CBOR? But this sounds similarly to our use-case for our proprietary LYB format, which uses schema node hashes instead of SID, but is also a binary format.