Return-Path: 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 5E82BB34BAB8 for ; Sat, 7 Feb 2026 03:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_NONE=-0.0001, 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=yumaworks.com 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 x9172suodGz4 for ; Sat, 7 Feb 2026 03:07:33 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id AD043B34BAB1 for ; Sat, 7 Feb 2026 03:07:33 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-59b75f0b8ecso385564e87.3 for ; Sat, 07 Feb 2026 03:07:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770462447; cv=none; d=google.com; s=arc-20240605; b=hvt7+qd8QpHW4VfJNSyZF7vKT1VhHIO/0reBNBi5W25KU7LDCIo8G9l6Riq8hW+eCf HRtz2NTiMviVsJqPXGvgXcK1/W8OYiKGhjgWxE/qCGjuY0KCH8JON1SmxQijXD44GEW4 brvCrpvSBLAPxMo4AUc6jlDs9iCuxwhro8SYPYOcasACQBz3eNiTLbqXGJuDRot8XyS/ KboMOQDT18BCpmjI7vbiY61CsIvOy6+/+A8nQa2roa7RzaIei4qyhv75WifWCXUTaiia JQTYKIrwqCRwju+q2Lv+Nz6OGFXPzxJ9LqFLBNfzkb6BVg5d+w7kmx543X1AhEED4zJa pU5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=C82an5gEp+wnOWSCgPm2xr2ARyJmaFZglCKNBzeoS00=; fh=sNWoWzRhoLyR3Ji0a6ZvLgDaNW4Qy+4YGM6CP3rxiTA=; b=YbevVvUsiKdc/aQR/BKFfc4oPlCOgfrPa8cUA6kTDQRD7vMzK6Q3NGOIRyolyINQCa r1R1fPvt9moKNrOEaQ3ci40fQ6Fq/D4hstLIZJCnmHFu4zP1rgF+9oG3pA/JrW43vGvn +TagzlstDRPdxLf7gSB1/L8+gDrSYAFP/kXG9BpMvOrU4K9x4WKHkjXOHsS3XiFh5KiQ MGy22wXjL7vps053LiJWA8DvQzMzsjcgIvNoi5KqwAWvR/HbIlAhjmdmXLjpYqULj9WX pJ5aitV600Fi9a3WXZZFNb4g7cQTAJ/YQ9CHBJ3F1NoAthiq4iGl1NvcGbtGvaIAoHKy et5Q==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks.com; s=google; t=1770462447; x=1771067247; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=C82an5gEp+wnOWSCgPm2xr2ARyJmaFZglCKNBzeoS00=; b=Sua7/ImjR7Z5cu2WQGYcRg2aRIjOKXsBTzEvi6uO8arEt2zOsM1gm0tAFh3uQCitkX dT96UVVEz28A/ALVX1fLc1b3oaMDeDQj8E8KEtvUCMD8oFb5/HwZU//2GN0dZ4j7TKf9 t78R/SnJlnU2fuB6ik2ZBb4CsIrunDjtbcSMhsh1v4Ro66j86Yll47Sp8kK7u+LlLO91 rM/juD9unKonb4HFAwdZWUegCQD2eAlFVuNOOS1SJr49BsjGvlylJvbjalwbULtPIwVO KnDcD1Ndgc22kZgpvGh07adLQanNEB8nPhjHK2WQ10gK7EJ7R5UQMGbrmZZaMAkfoYxN DfPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770462447; x=1771067247; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=C82an5gEp+wnOWSCgPm2xr2ARyJmaFZglCKNBzeoS00=; b=WXvMkBoOglqZtfiMqgTrLkpjy1L44+hUApxxXW8URL1n/++Z1yxTKzEAf7Gaa7fArl wW/DdymKVADvV6QkKq2gprIoNAXszmh9sWLPGPTCK0ZtQ4+0MhNjNvkPo/1wDK3jaw/L teseITXC6horEZ0GeCj1PsTaKbkSf3OUmtzBaALcSHht4lySat0dBk1fJjp1W/VtM6Cf Drx8P9Z18WqpPMK/4bwVejTIQkjccmzMTYPI0XRjz1MYWb9E4dpxFt3W6OwfaRUPa1YS Vbrsdvmge3tko7JQeny2IWceYMd1+EA1YtIZ/PCVPojqt+hoRe8eJTR1dAxKdz2HudsD e50Q== X-Gm-Message-State: AOJu0YxVA9PjumxvJVISPPl06LfAs/hZsmbIffQNLPek+Jb5CHAnaiC3 1O6yBjRr1Y6NbCYhOaN0bK+lKLEezJY5O4sb9sH1BPCJj9ZdJMa/DtXb0rWcnAQiZPynNpRLFNw slEwWPI1qUvaVlFb//03z1mwXH+x26ehWgZ8W4Jo5DiCsh3iLYEQSrrk= X-Gm-Gg: AZuq6aKdYHlq1cZ9Jr1cZdbv35q33UIPjq6J+vvoRmxLwNy86enHzjYbP3LGE90Kbpw mUDNuhVtEn1Ngz3+LnP93fzB0JLQr+J1dUU6FeFgfFj9cswyvZ8I92FM++JcRQAZ1xlMP/s3WRv HaL3Thv5a9o0WwxFh4iRV8o3Et0pfV8SY9JOkUStSIL37koECX8G7gFzA89OovIYQXXmfBEgkoV +9aZnuc4hXVg/6KAo7IbPG3sLI5bBxb4G43C4ZuuzoNYCSd+tTBlq5aO7XCuswl9aWSrpJs4tm2 bk8bu/6SBco= X-Received: by 2002:ac2:4bd6:0:b0:59e:3adc:6aed with SMTP id 2adb3069b0e04-59e4516e929mr1074570e87.5.1770462446913; Sat, 07 Feb 2026 03:07:26 -0800 (PST) MIME-Version: 1.0 References: <1517396.1770457190@dyas> In-Reply-To: From: Andy Bierman Date: Sat, 7 Feb 2026 03:07:14 -0800 X-Gm-Features: AZwV_QhCv5_K-87y1ROwIZoQ9dFkSCt2SDjRQvExyzgPvlJfbOBVuE4oBkfPvq0 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary="0000000000003c9a09064a39e952" Message-ID-Hash: 635KDW74FHNVGIIMENVKQME5DFS6XG4J X-Message-ID-Hash: 635KDW74FHNVGIIMENVKQME5DFS6XG4J X-MailFrom: andy@yumaworks.com 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: =?utf-8?q?=5Byang-tooling=5D_Re=3A_file_name_conventions_for_sid-file-versio?= =?utf-8?q?n?= List-Id: "Contributing to and tracking the progress of YANG tooling, as it concerns IETF work that uses YANG." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000003c9a09064a39e952 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 7, 2026 at 1:59=E2=80=AFAM Andy Bierman wr= ote: > > > On Sat, Feb 7, 2026 at 1:39=E2=80=AFAM Michael Richardson > wrote: > >> >> Andy, I think you are saying that we need conventions around naming (and >> searching >> for) sid files. Perhaps the file name should not be required by the >> tool, >> but usually derived from the module names + version. >> (having an override is fine, particularly for testing) >> >> Andy Bierman wrote: >> > For YANG modules that use external groupings, it is possible that = a >> > future release from a server vendor will upgrade an imported modul= e >> > with groupings, but not the module using the groupings. Only the >> > modules that use the grouping in data-def-stmts get SID assignment= s. >> >> That seems entirely reasonable >> >> > Updating a megarage is harder than generating a new one. In this >> case, >> > the module revision date does not change. Only the sid-file-versio= n >> > changes. >> >> To repeat: The imported module version changes, but the module using the >> grouping did not get a new version. Yet, it's changed because of the >> imported grouping.... >> > > > top@2022-01-01: > > container top { > uses foo:stuff; > } > > > foo@2020-01-01: > > grouping stuff { > leaf A { type string; } > } > > top@2022-01-01.sid > > 1000 module top > 1001 data /top > 1002 data /top/A > > foo@2025-01-01: > > grouping stuff { > leaf A { type string; } > leaf B { type string; } > } > > On 2025-01-01 the server vendor updates module foo and module top is not > edited at all. > Therefore the version of top is not changed, and there is no reason to > change it. > Yet the SIDs have changed. > > top@2022-01-01.1.sid > > 1000 module top > 1001 data /top > 1002 data /top/A > 1003 data /top/B > > We don't want 2 files named top@2022-01-01.sid but with different > contents.(I hope) > > > Maybe it is not obvious how bad this problem gets. (especially since large YANG models rely heavily on external shared groupings). A server vendor is under no obligation to change the revision of 'foo' that it is using. The SID file for 'top' depends on the modules the server vendor chooses to ship for a particular product and release. It does not depend solely on the contents of 'top'. Let's say 'top' is really an IETF or OpenConfig module where the vendor has no ability or authority to republish the SID file. Now multiply the number of imported modules that can be different, and just one SID file could have 10 different versions. The server vendor wants to upgrade module 'foo' because customers are demanding the new leaf 'B'. But the server vendor can only update its YANG library, and has no way to properly update the SID files. If SID Lifecycle is impossible to manage, then there will not be any SID files. Andy >> > Should the new SID file be named the same, and overwrite the last >> file >> > with the same module/revision date? If so, then there is no way t= o >> > tell whether a new SID file is in use from the filename. Also, th= e >> old >> > file name is still in use in lots of deployed code. >> >> I'm not quite following you here. >> >> > IMO a new file name is needed: >> > module-name@revision-date.sid-file-version.sid >> > module1@2025-01-01.1.sid >> >> > The sid-file-version is omitted if it is zero. >> >> -- >> Michael Richardson , Sandelman Software Works >> -=3D IPv6 IoT consulting =3D- *I*LIKE*TRAINS* >> > > Andy > > --0000000000003c9a09064a39e952 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Feb 7, = 2026 at 1:59=E2=80=AFAM Andy Bierman <andy@yumaworks.com> wrote:


On Sat, Feb 7, = 2026 at 1:39=E2=80=AFAM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Andy, I think you are saying that we need conventions around naming (and se= arching
for) sid files.=C2=A0 =C2=A0Perhaps the file name should not be required by= the tool,
but usually derived from the module names + version.
(having an override is fine, particularly for testing)

Andy Bierman <an= dy@yumaworks.com> wrote:
=C2=A0 =C2=A0 > For YANG modules that use external groupings, it is poss= ible that a
=C2=A0 =C2=A0 > future release from a server vendor will upgrade an impo= rted module
=C2=A0 =C2=A0 > with groupings, but not the module using the groupings.= =C2=A0 Only the
=C2=A0 =C2=A0 > modules that use the grouping in data-def-stmts get SID = assignments.

That seems entirely reasonable

=C2=A0 =C2=A0 > Updating a megarage is harder than generating a new one.= =C2=A0 In this case,
=C2=A0 =C2=A0 > the module revision date does not change. Only the sid-f= ile-version
=C2=A0 =C2=A0 > changes.

To repeat: The imported module version changes, but the module using the grouping did not get a new version.=C2=A0 Yet, it's changed because of = the
imported grouping....


to= p@2022-01-01:

=C2=A0 =C2=A0 container top {
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses foo:stuff;
=C2=A0 =C2=A0 =C2= =A0}


foo@2020-01-01:

=
=C2=A0 =C2=A0 grouping stuff {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 leaf A { type string; }
=C2=A0 =C2=A0 =C2=A0}
top@2022-01-01.sid

=C2=A0 =C2=A0= 1000=C2=A0 module top
=C2=A0 =C2=A0 1001=C2=A0 data /top
=C2=A0 =C2=A0 1002=C2=A0 data /top/A

foo@2025-01-01:=

=C2=A0 =C2=A0 grouping stuff {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 leaf A { type string; }
=C2=A0 =C2=A0 =C2=A0= =C2=A0 leaf B { type string; }
=C2=A0 =C2=A0 =C2=A0}
<= br>
On 2025-01-01 the server vendor updates module foo and module= top is not edited at all.
Therefore the version of top is not ch= anged, and there is no reason to change it.
Yet the SIDs have cha= nged.

top@2022-01-01.1.sid

=C2=A0 =C2=A0 1000=C2=A0 module top
=C2=A0 =C2=A0 1001=C2= =A0 data /top
=C2=A0 =C2=A0 1002=C2=A0 data /top/A
=C2=A0 =C2=A0 1003=C2=A0 data /top/B

We don'= t want 2 files named top@2022-01-01.sid but with different contents.(I hope= )




Maybe it is not obvious how bad this problem gets.
(especially since large YANG models rely heavily on external shared= groupings).

A server vendor is under no obligatio= n to change the revision of 'foo' that it is using.
The S= ID file for 'top' depends on the modules the server vendor chooses = to ship
for a particular product and release.=C2=A0 It does not d= epend solely on the contents of 'top'.

Let= 's say 'top' is really an IETF or OpenConfig module where the v= endor has no
ability or authority to republish the SID file.=C2= =A0 Now multiply the number of imported
modules that can be diffe= rent, and just one SID=C2=A0file could have 10 different versions.

The server vendor wants to upgrade module 'foo' be= cause customers are demanding the new leaf 'B'.
But the s= erver vendor can only update its YANG library, and has no way to properly u= pdate the SID files.

If SID Lifecycle is impossibl= e to manage, then there will not be any SID files.


Andy


=C2=A0 =C2=A0 > Should the new SID file be named the same, and overwrite= the last file
=C2=A0 =C2=A0 > with the same module/revision date?=C2=A0 If so, then th= ere is no way to
=C2=A0 =C2=A0 > tell whether a new SID file is in use from the filename.= =C2=A0 Also, the old
=C2=A0 =C2=A0 > file name is still in use in lots of deployed code.

I'm not quite following you here.

=C2=A0 =C2=A0 > IMO a new file name is needed:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0module-name@revision-date.sid-file-ve= rsion.sid
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0module1@2025-01-01.1.sid

=C2=A0 =C2=A0 > The sid-file-version is omitted if it is zero.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *I*LIKE*TRAINS*

Andy
=C2=A0
--0000000000003c9a09064a39e952--