Andy Bierman <[email protected]> wrote: > On Tue, Jun 28, 2022 at 11:30 AM Carsten Bormann <[email protected]> wrote:
>> > Andy Bierman <[email protected]> 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.
I hate this.
1) it fails for data at rest, or which have to go through multiple steps.
2) if I'm trying to reduce code (and bugs) as well as network traffic, then
having a
thing that translates to/from the ascii date representation as an *OPTION*
is just a non-starter.
I'm okay with some extension to SID to inform the encoder/decoder.
I started a thread in cbor@, and I think that we should do the work in cbor@
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
