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

[Maria Matejka <[e-mail]>]

Hello Carsten and others,

On 2023-11-14 19:47, Maria Matejka wrote:
> On 2023-11-14 19:02, Carsten Bormann wrote:
>> 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.
[snip]
>> 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.
I was thinking about how such a proposal should look like … [snip]
>>
>> 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.
>
… and what I'm coming to, is standardizing a YANG extension. And before 
I slide down the rabbit hole, I'd like to check that it makes any sense 
at all.

The problem is that these "canonical extended types" are actually 
defined as YANG derived types (typedef) by RFC 6991, so adding some 
update to RFC 9254 doesn't look like a viable option by itself, because 
it would need the CBOR-capable transcoders to selectively ignore these 
core parts of the YANG ecosystem. This smells to me of adding more worms 
to an already full can.

Also, I'd like to be futureproof – if somebody finds a new, better 
format to store structured data, they shall have a possibility to define 
these RFC-6991 types. The same goes with other types defined externally 
– if somebody wants to define a type which is "just a binary blob 
usually formatted in a fancy way", which IP addresses definitely are, 
I'd like to provide them with a standardized possibility to actually 
define them as (tagged) blobs for CBOR.

So I'm proposing to define a extension based on RFC 6020, § 7.17:

module cbor {
   extension tag {
     description "This type or container SHOULD be encoded in CBOR as a 
structure with this tag";
     argument number;
   }
}

… eh, but this requires the number to be written as a string, shame. Is 
it worth making the draft also to update RFC 6020, to add a "type" 
option to the "extension" clause, to allow for writing typedef 
ipv6-prefix { type string { … }; cbor:tag 54 } without the quotes?

And then we shall update RFC 6991 by adding these tags. The actual 
representation is needed to be implemented by CBOR transcoders anyway, 
so we don't have to bother about what is hidden behind the tag number … 
or should we?

This way, the draft would have 3 parts (apart from the needed headers, 
footers and so):

 1. Update to RFC 6020 to allow for typed extension argument
 2. Definition of the cbor encoding module using the updated extension
    definition
 3. Update to RFC 6991 stating all the tags involved

I'll be happy if I get some feedback to this idea before I actually 
start typing the draft and implementing this in our tooling to showcase 
that it indeed works.

Thank you and sorry for writing obnoxiously long sentences and have a 
very happy new year (if your new year started yesterday as well as mine)!

Maria

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