Re: [core] [Anima] date-and-time and "created-on" field in constrained-voucher

[Andy Bierman <[e-mail]>]

On Wed, Jun 29, 2022 at 8:09 AM Carsten Bormann <[e-mail]> wrote:

>
> > So your proposal is for the sender to check every single string it sends
> to the receiver to
> > see if some complex 20 byte string can be changed to an 8 byte integer
> instead?
>
> In an actual implementation, these 20 byte strings never exist.
>
> How a sender finds out that the 4-byte integer is enough is not specified.
> The answer is probably: because the data were in platform time format, and
> we just don’t do a strftime but a memmove(..htonl(..)).
>
>
The sender and receiver need to agree on the encoding of each schema item.
There can be no guessing.  But maybe this is a protocol issue and can be
addressed there.

Since this is a property of the CBOR encoding and not the YANG model itself,
adding more YANG statements seems like the wrong approach.
Extensions are possible but completely optional-to-implement.
Republication of all the modules that use date-and-time to add the
extension is not practical.

IMO the typedef replacement equivalency discussed in 7950, sec. 11 is not
important.
It is no burden at all to just use the correct 'date-and-time' data type.
There are no real examples of the plain string approach Juergen mentioned.
It is not a valid use-case.


Andy


> This seems rather CPU-intensive and not very useful for YANG Push.
>
> The way you describe it definitely is.
> But the specification would not stop you from doing do this, just your
> implementation common sense.
>
> > I doubt constrained devices have enough CPU for this, or that they need
> to send
> > lots of date-and-time data nodes to justify it.
>
> So far we have:
>
> — date-time and friends (as POSIX time integer): CBOR tag 1
> — IP addresses and friends (as binary): CBOR tag 52 and 54
>
> Fortunately, “type binary” is an actual base type, so here we already have
> actual schema support and therefore support in YANG-CBOR as is.
>
> > The date-and-time typedef for a string is not special in YANG in any way.
> > Just another derived type defined in a YANG module.
>
> Indeed, this is the reason why it is hard to do this properly (i.e.,
> deterministically in a way that it is guaranteed that every generator gets
> the choice right) without additional language support.
>
> Grüße, Carsten
>
>