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

Carsten Bormann <cabo@tzi.org> Sat, 07 February 2026 13:05 UTC

Return-Path: <cabo@tzi.org>
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 49BCEB34F36C for <yang-tooling@mail2.ietf.org>; Sat, 7 Feb 2026 05:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.389
X-Spam-Level:
X-Spam-Status: No, score=-4.389 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_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=tzi.org
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 POO7wd7bUo-f for <yang-tooling@mail2.ietf.org>; Sat, 7 Feb 2026 05:05:43 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::21]) (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 11900B34F367 for <yang-tooling@ietf.org>; Sat, 7 Feb 2026 05:05:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tzi.org; s=2019; t=1770469541; bh=/thmuuoDH4SUbUvXPHD3YCo/bC6OZvcat8SH/M3xi5M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YBjc9njDH2z2DzXTLgAFP1VEchC9N7VEEgA3xInvU5376+d7sOAx3weWaZr/R22bH 60tEt5T1XN4ObdSO9qcIIHOvyGxtWHuq1Vxv/Xrr/PBcmu7wEJRkxKYDl8rKMizkYw w0pqTOZcIA9TnZdjq/vo1oYGxJby/3pOFmj8ek9shT45MVGixhSEm6V5TF1LS6EQ16 nSJeNxS7xWOALrNIbp182EPWhBtxO6wz577zRr0Qbhkl7zFC2lCqBoK5j/dSgsVRlL 55z1rs5zBxOjRC12VZzMBt3CqQgmRCDriZBOJrzxU614MleMcz+3L3mYnc892D0xSG i1qVkJRpBX/Kg==
Received: from [192.168.217.132] (p548dcea3.dip0.t-ipconnect.de [84.141.206.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4f7WR920F2zDCbY; Sat, 7 Feb 2026 14:05:41 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <1520919.1770460646@dyas>
Date: Sat, 07 Feb 2026 14:05:40 +0100
X-Mao-Original-Outgoing-Id: 792162340.369137-9592727d355097e77b540cbb25955455
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C586095-1A0E-4F99-B7FD-6AB1FD822DB6@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> <7aca3e8e-ac46-4bb5-8b16-f75b51490b55@iotconsultancy.nl> <56406098-2B8F-402B-BE6A-AE9FEA9D7217@tzi.org> <CABCOCHQR30cSFqoFiYrj-PhX42r9o8zkSz9idVSOZYOyLD4A4A@mail.gmail.com> <ee28c8c1-fe81-4f9f-ba36-b60c74b5d156@iotconsultancy.nl> <CABCOCHR-oo5xK2bbagDUtK=1Mi5dBLjNT8r=4Y4QSJoFs0SgRA@mail.gmail.com> <b1256b3f-794b-40e8-a7e8-d1395fa7aa0d@iotconsultancy.nl> <EE144B22-21ED-46E8-8963-3D5639F377E9@tzi.org> <CABCOCHSzgtHZ3YpEwCrCtXBTFjusidzP3aCDbeJySM36toFoeA@mail.gmail.com> <81BE63E4-AB15-4 298-8A63-94726BD7F024@tzi.org> <CABCOCHTC-VTk5gBY7O95Au8eUF84pgVA2q4z7d8kY8N4hsFVtw@mail.gmail.com> <6E107270-5943-4615-A221-24FC6A66D914@tzi.org> <CABCOCHR32FgW_y54KTomJcD+kaFn_yqupr1-zCJJyHsPEoxX5g@mail.gmail.com> <CABONVQZTqmiGPW3WdEABPeLCwiJXoXxnWZqEo2zVVt0wLto-6g@mail.gmail.com> <CABCOCHR7NyT3BYqp7AWhKx30dYgLDc9bTPRMCDxYtgWBTw37_A@mail.gmail.com> <CABONVQYyuVaeUYiF2jVQP+WecntE3pdZ=S_9h3D=3OKmOaZYFg@mail.gmail.com> <CABCOCHSohiqD3knXA4BGbBRUz=QYS+JmfZy+KTfu_gwXs1x_ug@mail.gmail.com> <3A8390F8-C788-4174-A7E2-2872694AAD41@tzi.org> <CABCOCHQyU+a0EFK-Bfj2V5OpqaOYAAm4MAAtTyJpmXkgzEDuAQ@mail.gmail.com> <1520919.1770460646@dyas>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-FromAuthMilter: ok
Message-ID-Hash: STGY6NCW7VZBPIMNM6FND2L4ISMUY6P4
X-Message-ID-Hash: STGY6NCW7VZBPIMNM6FND2L4ISMUY6P4
X-MailFrom: cabo@tzi.org
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
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/3yYSlPWSVAsPCn9hRjV4wDh-A0s>
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>

On 2026-02-07, at 11:37, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
>> I don't really call it YANG if something as basic as choice/case is
>> ignored.
> 
> I think we can agree that it's an omission that needs fixing.

That was a deliberate choice, and what needs fixing apparently is mainly the “description” in the YANG module for .sid Files.

(Note that, while we are fixing the .sid File YANG module, that we may already be extending .sid Files to support SIDs specifically for metadata names [1], similar to how identities get their own namespace.)

[1]: https://mailarchive.ietf.org/arch/msg/core/totiCGYFFkh9mAZqL3otUnn0_iw/

>> Maybe a new SID file format for constrained devices should be developed
>> if the file does not actually identify schema nodes.  A SID file that
>> identified only data nodes might be suitable for 'structure' usage.
> 
> I haven't been down the CORECONF path (yet), but I would not include .sid
> files literally... I would process them through some build-time tooling that
> would generate code for my constrained device.

(I don’t usually look at “.sid” files before having processed them to CSV using the sid-csv tool.)

Grüße, Carsten