Re: [Cbor] [core] YANG-CBOR, Date formats

[Esko Dijk <[e-mail]>]

I see a simpler solution available now, for this date-format question. 

In draft-constrained-voucher we for example already define alternative representations using a leaf with another name.
For example, proximity-registrar-pubk is defined as a new field that can be used instead of proximity-registrar-cert, effectively specifying an alternative format for identification of a registrar.

We can do the same for date fields, e.g.
"created-on" -> "created-on-epochtime"
"expires-on" -> "expires-on-epochtime"

Where we can require in the YANG model that the new field is only of uint type; and point to the RFC 8949 section 3.4.2 definition.
The nice thing is that a Registrar or a MASA can easily handle either format, while the Pledge can be code-optimized to handle only the numeric uint format. (And MASA knows what the Pledge can support so will use the proper encoding the Pledge can understand.)

I suspect this can't be wrong, because we're doing the same for other fields (e.g. the proximity-registrar-cert as mentioned earlier.)

regards
Esko


-----Original Message-----
From: core <[e-mail]> On Behalf Of Carsten Bormann
Sent: Wednesday, June 29, 2022 15:37
To: Michael Richardson <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [core] YANG-CBOR, Date formats

> What SHOULD a compliant yang-cbor decoder *do* if it sees a representation
> node (I think that I used the right term), which is encoded using one of the
> standard RFC8949 tag types at:
>  https://www.rfc-editor.org/rfc/rfc8949#name-tagging-of-items

Answer: Croak.

There is a well-defined number of tags that can occur in YANG-CBOR.

Now, with the extension we are discussing, there would be a defined set of tags that have a translation: conceptually, these are translated into the equivalent YANG strings (1(1656449295) ➔ "2022-06-28T20:48:15Z"); in practice, they become the platform types that correspond to the tags.

You could define your own media type and simply specify that this transformation happens (conceptually, again) to turn the representation into the yang-data+cbor media type.

The breakage that could happen is that a generator misses converting a string into concise, or that a consumer breaks with non-concise form in a place that would allow a concise form.  That’s why it probably is a good idea to have something at the schema level — as a YANG extension (preferred) or hidden in the SID file.

                 .oOo.

The underlying problem is that you got what you wished for.

There is no need for YANG to define a security format.
Once it was decided to use YANG anyway, you had the baggage.

Now you are complaining that YANG-CBOR didn’t magically carry that baggage.

I think the learning is a different one:  
Don’t light your kitchen stove with a flame thrower.

Grüße, Carsten

_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core