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

[Andy Bierman <[e-mail]>]

On Tue, Jun 28, 2022 at 11:30 AM Carsten Bormann <[e-mail]> wrote:

> > Andy Bierman <[e-mail]> wrote:
> >> I am not in favor of the YANG-CBOR draft defining special encodings for
> >> 1 derived type (like date-and-time).  Implementations may not store the
> >> named YANG typedefs defined in various YANG modules.
> >> The current draft (properly) addresses only the base types, not derived
> >> types.
> >
> > So, do you think that auxiliary drafts could/should be written to deal
> with special
> > encoding of derived times?
>
> Well, first of all we need an architecture that explains how to do this.
> (Who needs to know what to make this happen.)
>
>
The key design goal is the YANG modules do not need to be modified to
provide efficient encoding options for CBOR.  Instead, tags are used
to indicate an alternate encoding is sent on the wire.

Each protocol needs a "server capabilities" discovery mechanism.
For example, NETCONF has a <capability> URI, but the current practice
is to design a protocol-independent YANG module for the client to read.

During the protocol setup, the client and server agree on which supported
tags
will be used (or maybe the protocol dictates this list).

During operation, the optimized encoding is used for any objects with the
data type.  E.g., tag X for date-and-time, tag Y for ipv4-address, tag Z
for ipv6-address.
The receiver is responsible for converting the special encoding to the
correct format
for the YANG data type.  Storage and exposure of the optimized format are
possible,
but (perhaps) not required.



Then we need a set of YANG-defined data types (which may or may not be
> congruent with a chosen set of CBOR tags such as 0, 1, 52, 54, etc.) that
> map to CBOR.
>
> The architecture will need to define whether the mapping can be
> schema-free or needs to be schema-informed (let me guess we’ll come up with
> the latter), which can be decided separately for the encoder/packer and the
> decoder/unpacker (which may be unpacking only at the architecture, but not
> at the implementation level).
>
> Whether this set is easily extensible, or only via a massive version
> up-ratchet, the architecture will need to define.
>

It is possible to do a combination of both, but for simplicity, a
hard-wired set
of the most relevant data types would be fine.



> Grüße, Carsten
>


Andy