Hi Michael, Toerless, In the BRSKI design team call we just discussed if the value of a YANG defined attribute encoded in CBOR could be a CBOR map, or not. I found the specification here for how to use the CBOR map: https://datatracker.ietf.org/doc/html/rfc9254#name-the-container-and-other-nod (Section 4.2) and CBOR list is in 4.4 of RFC 9254.
So a YANG hierarchical data container always maps to CBOR map/list, and inside it automatically supports the delta encoding and/or absolute value encoding inside it. (With arbitrary nesting depth it seems.) If a vendor wants to include some private data in the CBOR format as a map of (key, value) items where each key is *not* a SID, but just some private vendor’s number or private string, then the vendor would have to encode the map as a CBOR byte string (bstr) as we discussed. This maps to the YANG type “binary” (Section 6.8 of 9254) where the length can be arbitrary. For such vendor-specific data in a (hidden in bstr) CBOR map, the vendor could do either one of below: 1. Register a new SID number with IANA using a new tbd procedure (which we’re considering for RFC8366-bis now). This number would be outside the “voucher” module range which is controlled by IETF. 2. Use a standard SID number in the “voucher” SID module range, where the standard number is to be defined by IETF as “any binary vendor-specific data of any length”. This allows a more compact encoding and also enables the vendor to skip the IANA registration. Offering both options can also be considered – some vendors may want to add multiple new/semi-private YANG attributes; which requires approach 1). While others would prefer 2). Whatever we come up with probably also has to map to JSON vouchers! Regards Esko
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
