[yang-tooling] Re: SID file issues / .sid file differences in pyang and core-wg/pyang

Esko Dijk <esko.dijk@iotconsultancy.nl> Wed, 04 February 2026 14:13 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: yang-tooling@mail2.ietf.org
Delivered-To: yang-tooling@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AC756B1C34D2 for <yang-tooling@mail2.ietf.org>; Wed, 4 Feb 2026 06:13:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iotconsultancy.nl
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBHkYH7-11AS for <yang-tooling@mail2.ietf.org>; Wed, 4 Feb 2026 06:13:47 -0800 (PST)
Received: from dane.soverin.net (dane.soverin.net [185.233.34.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E8225B1C34CD for <yang-tooling@ietf.org>; Wed, 4 Feb 2026 06:13:46 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.4.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4f5j4z0N81zwfY; Wed, 04 Feb 2026 14:13:39 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4f5j4y4DHXzCw; Wed, 4 Feb 2026 14:13:38 +0000 (UTC)
Authentication-Results: smtp.soverin.net; dkim=pass (2048-bit key; unprotected) header.d=iotconsultancy.nl header.i=@iotconsultancy.nl header.a=rsa-sha256 header.s=soverin1 header.b=BK8A27LP; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=soverin1; t=1770214418; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VY5BkqMTJevTgU/tQnmXv7k0cfDQU6y7BXjuQwRL2JI=; b=BK8A27LP940DCyqHG219cbdI1QMaeIuxlpwOzSJtX4+pWWpaYhiSAXsEA3dT2Wx5sQalgA bkS9T8wEyfE3eyyj33wM1CPl4FJ6p2piD7WyZ4gYppvtA3fscb0zcTjQ0OLn7ujmFf4U1y y2KK2WHy+7/VBX8F37rNRyfNy08rYGDp8y7tyXVe8zwXFv2RZjDn2361K/ssIVDAi6DqSC 5yTdkDeVKeL8cfPeUe76dO9M8kXlHDeggiAJWsGmgH/SozISkVFr/Z8UPQqiHhm9jSjHs7 clMtoACKqarGB3wsH38fY9X7U2o/2fAoP00DWRZf1R2Kek5mU+R9qLD1wS9iWw==
X-CM-Envelope: MS4xfCG4KVxJUwE9OCyV0iEJnL8YRRUQWTnNT9Ugato7bZrQ3k73lqtYNh+sE+379a53MDQt8G3KNvGMC13zi2/xFDq7ZeCIuqa+wgzN1ZxjuoTWcwXS2E6h r+GVOLrGkXg2xFPB93EUgBdh09KUV8egxmWwY39UT90W8Nu8p1rYHwYRhgA17bIQWAVHQ5BByJdjqIRy+fLGLY3eTS+GQ4Kdr9sXULC15x9k4WsDB1W7cCQb z3umZCoXvhHdLEoGjv6qK/Dasd2SmWBxn50wvkksXRg=
X-Soverin-Id: 019c2900-6650-7b3f-8787-78650f6fed5b
Message-ID: <7aca3e8e-ac46-4bb5-8b16-f75b51490b55@iotconsultancy.nl>
Date: Wed, 04 Feb 2026 15:13:37 +0100
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
References: <CABCOCHTP52cfDVeguY3iYbzJqmCfg-z5cMeFz-y_3vNw250TEg@mail.gmail.com> <1263365.1770129015@dyas> <CABCOCHRHAEkiAJu=TtaZDERG9eiq_Ay9txRt10DEOgPYu3eprA@mail.gmail.com> <6c4f3e7e-ffa3-404b-83b3-9533f4046212@iotconsultancy.nl> <CABCOCHTWV2amW1wdHPQyd5jeaAVeie1S2xFfFf2ZgZQ6EbCKqg@mail.gmail.com> <4c11110f-fe64-414f-ad78-0183c61851b8@iotconsultancy.nl> <DDC68541-9A77-4AFD-BF36-DF6A75CF888B@tzi.org> <ce89bf21-8806-4590-9f37-a1eefa44b979@iotconsultancy.nl> <408BA8A1-AD8E-4CED-9991-B4632577986E@tzi.org>
Content-Language: en-US
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
In-Reply-To: <408BA8A1-AD8E-4CED-9991-B4632577986E@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Spampanel-Class: ham
Message-ID-Hash: K6XXNBL3U4FZMNJ257R7BGN7R3VV36OL
X-Message-ID-Hash: K6XXNBL3U4FZMNJ257R7BGN7R3VV36OL
X-MailFrom: esko.dijk@iotconsultancy.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: yang-tooling@ietf.org, Andy Bierman <andy@yumaworks.com>, Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [yang-tooling] Re: SID file issues / .sid file differences in pyang and core-wg/pyang
List-Id: "Contributing to and tracking the progress of YANG tooling, as it concerns IETF work that uses YANG." <yang-tooling.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-tooling/tOX1HMufRjwIvtanXTofVWSNSo0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-tooling>
List-Help: <mailto:yang-tooling-request@ietf.org?subject=help>
List-Owner: <mailto:yang-tooling-owner@ietf.org>
List-Post: <mailto:yang-tooling@ietf.org>
List-Subscribe: <mailto:yang-tooling-join@ietf.org>
List-Unsubscribe: <mailto:yang-tooling-leave@ietf.org>

Hi Carsten,

I thought "YANG item" is defined in RFC 9254 Section 2:

item:
     A schema node, an identity, a module, or a feature defined using 
the YANG modeling language.

So this would include the choice/case schema nodes.

Or is there a difference between "YANG item" and "item" ? -- in which 
case I'm officially lost. Interestingly RFC 7950 doesn't define "YANG 
item" but still uses the term.


If it was not intended to assign a SID to each "item", but rather only 
to a subset of items i.e. the ones listed in Section 3.2 of RFC 9254, I 
can understand that.
If we assign to all "items" then we get quite some SID values that 
aren't used in practice, in an actual data tree serialization in CBOR. 
This sounds less useful for a majority of use cases.

If we assume that SIDs only assigned to a subset of items is the 
intention of RFC 9595, this this text and maybe 9254 would need fixing I 
believe.

Can you confirm that YANG item is the same as "item" in RFC 9254, or 
otherwise give some hints about their (intended) difference?

Esko


On 2/4/26 13:33, Carsten Bormann wrote:
> On Feb 4, 2026, at 13:07, Esko Dijk <esko.dijk=40iotconsultancy.nl@dmarc.ietf.org> wrote:
>> assign a SID value to each "YANG item”
> Now what *is* a YANG item?
>
> The observation that the YANG terminology is less usable than we thought came relatively late in the processing of YANG-CBOR (RFC 9254), so you’ll have to excuse us not properly defining that term.
>
> Section 3.2/3.3 of RFC 9254 seem to provide the best definition.
>
> 3.2 lists the items we want SIDs to be useful for.
> Note the absence of choice/case.
>
> 3.3 describes the naming of YANG items as text strings, which are the same ones that would occur in “.sid” files.
> This section closely relates these text strings to the ones used in YANG-JSON (RFC 7951).
> (The terms “choice” and “case” do not occur in the YANG schema node sense in RFC 7951, which is probably why they don’t occur much in RFC 9254 either.)
>
> RFC 9254 is pretty much silent about “choice” and “case”.
> The one occurrence of “choice” in the RFC, Section 4.4, comes with a YANG-CBOR instance which appears to ignore the presence of choice and case schema nodes.
>
> RFC 7950 (YANG/YANG-XML):
> 7.9: A choice node does not exist in the data tree.
> 9.13: It [instance identifier] is used to uniquely identify a node in the data tree.
>
> The main purpose of SIDs/YANG item names is to build instance identifiers; this may have shaped my interpretation of how the strings that serve as YANG item names should be constructed.
>
> Grüße, Carsten
>