Re: [Cbor] CBOR-YANG representation of common types

[Maria Matejka <[e-mail]>]

Hello Carsten!

On 2023-11-14 19:02, Carsten Bormann wrote:
> Hi Maria,
>
> On 2023-11-14, at 17:54, Maria Matejka<maria.matejka=[e-mail]>  wrote:
>> Dear CBOR WG,
>>
>> we're currently trying to embrace the CBOR described by YANG in BIRD interface and we're struggling with the representation of certain types like date, time, IP address or prefix. We would assume that if there is RFC 9164 or RFC 8943, we shall then encode dates or IP addresses in these defined formats in CBOR and they shall get converted between CBOR and JSON/XML appropriately. But I can't find any RFC on this, nor any implementation of CBOR-JSON convertor.
> These types are all defined as text string types in RFC 6991 etc. (and RFC 6991bis does not change anything about this).
> RFC 9254 defines a basic representation of YANG in CBOR, not trying to change this.
That's why I'm asking. It just doesn't seem to be coherent altogether, 
just per partes.
>> Thus, these questions arise:
>>
>> 	• Is there any discussion on this topic, regarding interoperability between CBOR and JSON/XML?
> This is a timely question.
> There definitely is discussion, as the representation of these types as a CBOR text string is inefficient (with respect to both space and CPU time).
>
>> 	• Is there any RFC on draft on this? If not, we're probably gonna create one. We need it
> Writing up a proposal is on my to do list.
> Right now I’m looking at:
>
>       typedef object-identifier {
>         type string {
>       typedef object-identifier-128 {
>         type object-identifier {
>           pattern '\d*(\.\d*){1,127}';
>       typedef date-and-time {
>         type string {
>       typedef phys-address {
>         type string {
>       typedef mac-address {
>         type string {
>       typedef hex-string {
>         type string {
>       typedef uuid {
>         type string {
>       typedef dotted-quad {
>         type string {
>       typedef ip-address {
>         type union {
>           type inet:ipv4-address;
>           type inet:ipv6-address;
>       typedef ipv4-address {
>         type string {
>       typedef ipv6-address {
>         type string {
>       typedef ip-address-no-zone {
>         type union {
>           type inet:ipv4-address-no-zone;
>           type inet:ipv6-address-no-zone;
>       typedef ipv4-address-no-zone {
>         type inet:ipv4-address {
>       typedef ipv6-address-no-zone {
>         type inet:ipv6-address {
>       typedef ip-prefix {
>         type union {
>           type inet:ipv4-prefix;
>           type inet:ipv6-prefix;
>         }
>       typedef ipv4-prefix {
>         type string {
>       typedef ipv6-prefix {
>         type string {
>
> This can use tags from RFC 8949, RFC 9164, RFC 9090; we probably need to discuss little details such as whether tag 23 can be used for hex-string.

These are the most needed, surely, at least for us. Anyway, other RFC's 
and drafts tend to define additional types as strings (yes, I'm looking 
at you, BGP YANG draft) so what I'd like to see, is not only explicit 
definition of these, but maybe also a future requirement or at least 
some extension of YANG itself, to allow for defining some type both as a 
string in JSON and XML, and as a specific format in CBOR, e.g. like this:

typedef ipv6-address-no-zone {
   type string { … };
   compact type {
     tag 54;
     blob;
   };
}

typedef ipv6-prefix {
   type string { … };
   compact type {
     tag 54;
     uint length;
     blob prefix;
   };
}

but it inevitably leads to weird problems where the CBOR representation 
is more structured and in fact is a grouping. I'm not sure yet how to 
handle this but I still refuse to believe that we're all screwed into 
the string representation, this way the other way around compared to the 
****** with SNMP MIBs.

In any case, if you happen to start writing this, please keep us 
informed. If we happen to go on this first, we'll tell you as well. 
Having this as a critical priority for us, it's even possible that you 
have the first draft here tomorrow. (Exaggerating, but not much.) What 
is the right platform to collaborate on?

>> 	• Is there any implementation of YANG-ed converter between CBOR and JSON? If not, we're probably gonna create one. We need it.
> Laurent Toutain has a tool that extracts from a YANG module the parameter information needed for such a YANG-CBOR ⬌ YANG-JSON converter today.
> This tool uses base types, so it cannot quite address the above list.
> But the idea should be transferable.

OK. Can't find that so we're probably going to make our own tool for the 
conversion or whatever. We need it anyway and it probably has to be 
really fast.

Have a nice day! Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.