Hi NETMOD Chairs, Can we close on this WGLC?
> On May 4, 2026, at 12:49 PM, Andy Bierman <[email protected]> wrote: > > > > On Mon, May 4, 2026 at 12:29 PM Per Andersson <[email protected] > <mailto:[email protected]>> wrote: >> On Sun, May 3, 2026 at 6:04 PM Andy Bierman <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > >> > >> > On Tue, Apr 28, 2026 at 1:51 PM Per Andersson <[email protected] >> > <mailto:[email protected]>> wrote: >> >> >> >> On Tue, Apr 28, 2026 at 7:53 PM Andy Bierman <[email protected] >> >> <mailto:[email protected]>> wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Apr 27, 2026 at 3:41 PM Lou Berger <[email protected] >> >> > <mailto:[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. >> > > > > 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. > > [email protected] <mailto:[email protected]> > > 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 >> > [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] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
