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

Christian Amsüss <> Tue, 29 June 2021 18:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3971E3A3C9E; Tue, 29 Jun 2021 11:14:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rPhC2EerntW5; Tue, 29 Jun 2021 11:14:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B7F13A3C59; Tue, 29 Jun 2021 11:13:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 9647540128; Tue, 29 Jun 2021 20:13:51 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id D00BC74; Tue, 29 Jun 2021 20:13:50 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPSA id 817C826; Tue, 29 Jun 2021 20:13:50 +0200 (CEST)
Received: (nullmailer pid 2053110 invoked by uid 1000); Tue, 29 Jun 2021 18:13:50 -0000
Date: Tue, 29 Jun 2021 20:13:50 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <>
Message-ID: <>
References: <YNtT13MO/>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <YNtT13MO/>
Archived-At: <>
Subject: Re: [core] core-yang-cbor-mapping: CBOR tag review
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jun 2021 18:14:32 -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:

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?


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