On Mon, May 4, 2026 at 12:29 PM Per Andersson <[email protected]> wrote:
> 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. > > 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] 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] To unsubscribe send an email to [email protected]
