On Mon, Jun 27, 2022 at 7:32 PM Michael Richardson <[email protected]> wrote:
> > Andy Bierman <[email protected]> wrote: > > This change is not backward-compatible and not allowed per RFC 7950, > sec 11. > > A new typedef with a different name is needed to allow the uint64 > encoding. > > Since RFC8366 uses yang:date-and-time, and our document derives from it, > short of revising RFC8366, is there something we can do to allow use to use > tag 1 when we encode in draft-ietf-anima-constrained-voucher? > > not that I know about > It sure seems like a major omission in yang-cbor, which is yes, approved, > but is just > AUTH48 today... > > 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. > (Noting that revising RFC8366 *is* on our agenda, just order of operations, > we didn't think we'd have to do that first) > > Andy > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
