[netmod] Re: limited WGLC: draft-ietf-netmod-yang-module-filename-10

[Andy Bierman <[e-mail]>]

On Mon, May 4, 2026 at 12:29 PM Per Andersson <[e-mail]> wrote:

> On Sun, May 3, 2026 at 6:04 PM Andy Bierman <[e-mail]> wrote:
> >
> >
> >
> > On Tue, Apr 28, 2026 at 1:51 PM Per Andersson <[e-mail]> wrote:
> >>
> >> On Tue, Apr 28, 2026 at 7:53 PM Andy Bierman <[e-mail]>
> wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Apr 27, 2026 at 3:41 PM Lou Berger <[e-mail]> wrote:
> >> >>
> >> >> All,
> >> >>
> >> >> We'd like to run a limited WG LC on
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/
> >> >>
> >> >> This LC has been requested by our AD (and we agree!) due to the
> significant technical changes in the document.  While the actual diff is
> small, see [1], the changes have notable implementation implications.
> Please limit your comments to the changes since the previous LC (version
> -05).
> >> >>
> >> >> This last call ends May 5.
> >> >
> >> >
> >> >
> >> > It looks like the syntax was changed beyond the '#' character:
> >> >
> >> > was:
> >> >
> >> >        module-or-submodule-name [['@' revision-date]['#' ysv:version]]
> >> >
> >> > now:
> >> >
> >> >        module-or-submodule-name ['@' (ysv:version) / (revision-date)]
> >> >
> >> >
> >> > Before there could be a revision-date and a semver string.
> >> > Now it looks like there can be one or the other.
> >>
> >> This was an error, it has never been the intention to be able
> >> to have both a revision date and a version simultaneously.
> >>
> >
> > This is a significant difference.
> > I think it makes the filename less deployable.
>
> That is not the experience I have. It is less disruptive,
> hence more deployable, than using another delimiter.
>
>


I meant that the syntax did allow both versions

   foo@2026-01-01#1.0.3.yang

I understand that existing tools will not work with these changes, but
they will not work with any changes. Changing the char to '@' does not
really matter.

   [e-mail]

It is not a big deal for someone to change the filename to whatever they
want (e.g. foo.yang),
after the file is extracted or downloaded.

I do not have any objections to the updated draft.


Andy




>
> > Obviously the semver pattern does not conform to RFC 7950  sec 5.2, so
> by using it,
> > a choice is being made to intentionally break YANG 1.1 tools.
>
> There is no intention to break tools.
>
> However, a quick survey shows:
>
> * yanglint breaks with both,
>
> * yanger warns with both @ and # but continues processing.
>
> * confdc warns with @ but creates the corresponding output,
>   but fails with error with #.
>
> See also my previous mail where the # delimiter broke pyang,
> but the semver pattern with the @ delimiter just worked.
>
>
>
> > RFC 9595 does not specify any filename requirements for SID files except
> the extension is .sid.
> > All examples and tools seem to use the revision date format in RFC 7950.
> >
> > RFC 9195 does specify a pattern:
> >
> > The name of the instance data file SHOULD be of the following form
> (using ABNF notation [RFC5234]):
> >
> >    instance-data-set-name ["@" ( revision-date / timestamp ) ]
> >                   ( ".xml" / ".json" )
> >
> > Examples include:
> >
> >       acme-router-modules.xml
> >       [e-mail]
> >       acme-router-modules@2018-01-25T15_06_34_3+01_00.json
> >
> >
> >
> > If the YANG module filename contains only a Semver, then it is not
> possible
> > to align this file with related files that use the revision date.
>
> I assume that the timestamp pattern is equally difficult for tools
> to correlate as a semver pattern would be, especially for all use
> cases listed in RFC 9195.
>
> I don't know if it is relevant to put a semantic version on instance
> data though. Because it is not necessarily correlated to the YANG
> module, right? It could be a temporal instance of data. See for
> instance Section 2.2.2 which have the file
> [e-mail] but the revision date is
> 2018-07-04, and the module used is ietf-netconf-acm@2018-02-14.
>
> I note also that in Section 2.2.3 it states
>
>     As a new set is produced periodically many times a day, a
>     revision-date would be useless; instead, a timestamp is included.
>
> Furthermore Section 1.2 Principles states
>
>     P4  A YANG instance data set shall be allowed to contain data for
>        multiple YANG modules.
>
> Which obviously decouples the instance data file name from the
> YANG module filenames, since these can have different revision
> dates.
>
> What parts of RFC 9195 are violated by yang-module-filename?
>
> Perhaps the authors of RFC 9195, Balazs and Benoit, can elaborate
> on the intent of the document?
>
>
> --
> Per
>
>
> >
> >>
> >> --
> >> Per
> >
> >
> >
> > Andy
> >
>