[yang-tooling] Re: file name conventions for sid-file-version

[Andy Bierman <[e-mail]>]

On Sat, Feb 7, 2026 at 1:59 AM Andy Bierman <[e-mail]> wrote:

>
>
> On Sat, Feb 7, 2026 at 1:39 AM Michael Richardson <[e-mail]>
> 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 <[e-mail]> wrote:
>>     > For YANG modules that use external groupings, it is possible that a
>>     > future release from a server vendor will upgrade an imported module
>>     > with groupings, but not the module using the groupings.  Only the
>>     > modules that use the grouping in data-def-stmts get SID assignments.
>>
>> 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-version
>>     > 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; }
>      }
>
> [e-mail]
>
>     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.
>
> [e-mail]
>
>     1000  module top
>     1001  data /top
>     1002  data /top/A
>     1003  data /top/B
>
> We don't want 2 files named [e-mail] 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 to
>>     > tell whether a new SID file is in use from the filename.  Also, the
>> 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:
>>     >     [e-mail]
>>     >     [e-mail]
>>
>>     > The sid-file-version is omitted if it is zero.
>>
>> --
>> Michael Richardson <[e-mail]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>>
>
> Andy
>
>