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

Esko Dijk <esko.dijk@iotconsultancy.nl> Thu, 05 February 2026 10:03 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 CE637B231043 for <yang-tooling@mail2.ietf.org>; Thu, 5 Feb 2026 02:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 HgO-DzuCeiAL for <yang-tooling@mail2.ietf.org>; Thu, 5 Feb 2026 02:03:33 -0800 (PST)
Received: from dane.soverin.net (dane.soverin.net [185.233.34.157]) (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 E5F93B23103C for <yang-tooling@ietf.org>; Thu, 5 Feb 2026 02:03:32 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.4.99]) (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 4f6CTm4yl6zbC; Thu, 05 Feb 2026 10:03:24 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4f6CTk517bz4kC; Thu, 5 Feb 2026 10:03:22 +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=rYSJNGPa; dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=soverin1; t=1770285804; 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: in-reply-to:in-reply-to:references:references; bh=7XMZDll+dQaJFisCRQwlcIcfEfbyvWD+hN7yureMt8Y=; b=rYSJNGPaIeRxbVVEdM5CKDFhHVTKvbJO8bqhB0izcXLcMeptjmIeVG0Fmn3CW0yZ5lCKMB 02Ktzx9waJWSQ03DpFOl8E8dbOrYFNgfzd0DYOL26ei4I+nmrA/NMBCRppalNGSgHu6a1J 2umr87+KBGUiY8zy5Z2muDqpKYB2jsIwWLH3dQBCyskEPgNPRVUOfEqrpVz4dFFyfauMPW nP5csiQKdSMa/I4D4pZGc2dXU34J3VlGZyOcH4c20a3OpDof9jdClpvlZA2YTX5kyiCZQX dLmtmppWUrnzyobGTrOgQSpjdcCW9MfpuenPe72v1pDbz6rsP4wyXWtrhy2YfQ==
X-CM-Envelope: MS4xfOQT/r463uV1y+2IomdktPWP3vl01bdK+osupOFhIscvZ6sC6+V29wk6PVh1yWKhFJy1LX23TDZhlGljGFsYSs29PZVY7wbZMCIStMG7YljDnyqcrgPu fPPKnRr2Bf4IVY6kYBDROZGKI9JzO1m/1cz5U02e/fHH97B8WMTIiJgFhZ59eDCR+N5OMywnRKaw4lhLNb6PbTAQtyArNh4g3FAxdWxtAB1eiQGGaKlYI+Px saZfsWj/chdqbgu9WuPIkePNA9KYYBabOQ/Geu4fnJA=
X-Soverin-Id: 019c2d41-a9e0-7303-b00f-ba91ceb804a8
Content-Type: multipart/alternative; boundary="------------LTtlvzPPaWi3NpS80AAkY399"
Message-ID: <b1256b3f-794b-40e8-a7e8-d1395fa7aa0d@iotconsultancy.nl>
Date: Thu, 05 Feb 2026 11:03:22 +0100
MIME-Version: 1.0
To: Andy Bierman <andy@yumaworks.com>
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>
Content-Language: en-US
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
In-Reply-To: <CABCOCHR-oo5xK2bbagDUtK=1Mi5dBLjNT8r=4Y4QSJoFs0SgRA@mail.gmail.com>
X-Spampanel-Class: ham
Message-ID-Hash: CQFKKJ7W7KFAUD6SV7OABI4DEBZ5Q75K
X-Message-ID-Hash: CQFKKJ7W7KFAUD6SV7OABI4DEBZ5Q75K
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: Carsten Bormann <cabo@tzi.org>, yang-tooling@ietf.org, 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/V3HNXzs-6uZvfFmk9rF8X6qbDag>
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>

Thanks Andy for your responses. Just to come back to one item:


On 2/4/26 17:27, Andy Bierman wrote:
>
>     > So anyplace a SID is needed, a path string could be used instead.
>     > (Current situation).
>
>     Shouldn't we  say "anyplace where in a CBOR data tree an instance
>     identifier string is used as a CBOR map key, a SID value could be
>     used
>     instead" ?
>
>
> no.

I think I've used the wrong term here: instead of "instance identifier 
string", the thing in a CBOR map key is called "name" (Section 3.3 of 
RFC 9254).

For a sender of a CBOR payload, such "name" string can always be 
substituted by its corresponding SID in a CBOR payload that conforms to 
a YANG module (for which SIDs have been assigned).

I was trying to confirm that this is correct and that the sender can 
arbitrarily select which names to substitute, e.g. a subset.

Esko