On Sun, May 3, 2026 at 6:04 PM Andy Bierman <[email protected]> wrote: > > > > On Tue, Apr 28, 2026 at 1:51 PM Per Andersson <[email protected]> wrote: >> >> On Tue, Apr 28, 2026 at 7:53 PM Andy Bierman <[email protected]> wrote: >> > >> > >> > >> > On Mon, Apr 27, 2026 at 3:41 PM Lou Berger <[email protected]> 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. > 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 > [email protected] > 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 [email protected] 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 > _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
