Subject: [core] core-yang-cbor-mapping: CBOR tag review

From: Christian Amsüss <[email-masked]>
Date: Tue, 29 Jun 2021 19:09:43 +0200

Hello YANG authors,

I've been asked by IANA to expert-review the tag allocations for
yang-cbor-mapping, and while I do see no fundamental red flags (which
would surprise me, given one of the registry experts is on the authors
team), I'd like to understand better a few aspects of the registrations:

* As I understand "YANG bits datatype" and "YANG enumeration datatype"
  from a cursory reading, these only exist to cover the corner cases
  where a numeric (be it compressed-bitfield or plain index,
  respectively) value doesn't cut it. When that corner case is hit, a
  compact representation is out of question (and if I were inclined to
  speculate I could imagine that if YANG were done with the benefit of
  hindsight, the unioned types would be somehow sorted to allow an
  unambiguious compact representation).

  My impression is that these would be used rarely in YANG models built
  for constrained devices, and when it does happen, can afford a place
  in the 1+2 range -- keeping the 1+1 for usages that *do* count bytes
  (which an application that can afford a literal "under-repair
  critical" probably does not).

* On the same tags, could you elaborate a bit on why tags are necessary
  for these? The format appears to be comfortable with having type-based
  disambiguation in several places; why can't a text string like
  "under-repair critical" not indicate by its major type that it's a
  union's bit names and not its bit value?

* For the tags "YANG identityref datatype" and "YANG
  instance-identifier", the reference given in the registration
  describes their content, but not how they are used. AIU they are
  primarily intended for expressing their tagged data in anyxml.

  If so, a note on that might be helpful, possibly along the lines of

  > Tags TBD43, TBD44 and TBD47 are used in CBOR encoded YANG trees to
  > disambiguate union items from the usual more compact
  > representations, and to disambiguate absolute SIDs from delta
  > encoded ones.
  >
  > TBD45 and TBD46 are defiend for use with anyxml (Section 4.6).

  Like for bits and enumerations, is this something you expect to find
  often in non-embedded-tailored YANG schemes? If not, they too might be
  good candidates for the 1+2 range.

As said, none of these are showstoppers, but I'd appreciate some
clarification.

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 29 Jun 2021 20:13:50 +0200

Hello YANG authors,

> team), I'd like to understand better a few aspects of the registrations:

there has been a mix-up -- the tags *are* already registered, so please
disregard any questions as to the 1+1/1+2 range.

The points about the internal references on usage stand (albeit more in
a "commenter late to the party" capacity).

A new point I should raise reviewing what will now be changes to the
registry is the type changes: tags 43 and 44 used to tag bstr and uint,
respectively. While there is no need in the RFC-to-be to dwell on its
draft history: Have implementations of this document followed the
changes that led to the altered tag payloads? If not, is there anything
better than bailing that implementers can do when faced with the tags as
they used to be used?

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater
powers.
  -- Bene Gesserit axiom