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

Christian Amsüss <christian@amsuess.com> Tue, 29 June 2021 17:09 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D313A3AFF; Tue, 29 Jun 2021 10:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLhsbalRQ_ul; Tue, 29 Jun 2021 10:09:49 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A63B3A3AFA; Tue, 29 Jun 2021 10:09:48 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 54C8A40128; Tue, 29 Jun 2021 19:09:45 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 5D91674; Tue, 29 Jun 2021 19:09:44 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [141.244.80.208]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2162C26; Tue, 29 Jun 2021 19:09:44 +0200 (CEST)
Received: (nullmailer pid 2044235 invoked by uid 1000); Tue, 29 Jun 2021 17:09:43 -0000
Date: Tue, 29 Jun 2021 19:09:43 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: draft-ietf-core-yang-cbor@ietf.org
Cc: core@ietf.org
Message-ID: <YNtT13MO/ccGhBoW@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I0oYkU6eSuT2R5G/"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/swoD09LTx_vbj4sethmV4C8umjE>
Subject: [core] core-yang-cbor-mapping: CBOR tag review
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2021 17:09:54 -0000

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