Re: [core] Genart last call review of draft-ietf-core-sid-15

Carsten Bormann <> Tue, 16 March 2021 17:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E77353A08A7; Tue, 16 Mar 2021 10:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QJIY7vYEhnGQ; Tue, 16 Mar 2021 10:59:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EB123A08A6; Tue, 16 Mar 2021 10:59:10 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4F0LdS5jD5zyhk; Tue, 16 Mar 2021 18:59:08 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Tue, 16 Mar 2021 18:59:08 +0100
X-Mao-Original-Outgoing-Id: 637610348.285911-b3962ab0ade0c8ecd2947fddcf81c725
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Linda Dunbar <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [core] Genart last call review of draft-ietf-core-sid-15
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, 16 Mar 2021 17:59:13 -0000

Hi Linda,

> On 2021-03-16, at 18:34, Linda Dunbar via Datatracker <> wrote:
> Reviewer: Linda Dunbar
> Review result: Not Ready
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-core-sid-15
> Reviewer: Linda Dunbar
> Review Date: 2021-03-16
> IETF LC End Date: 2021-03-17
> IESG Telechat date: Not scheduled for a telechat
> Summary:
> This document introduces the globally unique 63-bits integers to identify YANG
> items which include data nodes, RPCs, their associated inputs/outputs,
> notifications, YANG modules, submodules, and features.
> Major issues:
> - One of the benefits of YANG is its explicit naming and human-understandable
> notations. It will be a nightmare if all the YANG items are represented by
> integers. YANG items being represented by integers will be worse than the TYPE
> values in the TLVs. At least, the TLV types are in the context of the protocols
> and their messages. - It will be a tremendous amount of work to map all YANG
> items to globally unique integers. - YANG has been widely deployed without the
> numbering system. Which environment will need the integer representations? Who
> will validate the numbers used? How to validate the YANG modules represented by
> those "integers"?

These are all questions that were valid before this document was written.
The document now shows that this can be done, without any of the disadvantages you cite.

There never will be a need to map *all* YANG identifiers to YANG SIDs, as YANG-CBOR is designed to allow string identifiers as well (you can use YANG-CBOR entirely without using YANG SIDs).  But where encoding and lookup efficiency is important, YANG SIDs are the way to go, and the process for allocating and using them that we arrived at after years of discussion (including several rounds with IANA) makes them very much workable.

> - SID can be mistaken as Segment Identifiers (SID). Suggest using a different
> name.

Indeed, that’s why they are called “YANG SIDs”.

Grüße, Carsten