Hi Qin, Thanks for your review!
See responses inline. On Mon, Apr 27, 2026 at 3:22 AM Qin Wu <[email protected]> wrote: > > Hi, Mahesh and all: > > I haven’t seen the WGLC is coming, here are a few comments I would like > authors to consider: > > 1. I-D.ietf-netmod-rfc8407bis should be replaced with RFC9907. Done, thanks! > 2. Lack of coherence > > Section 2.1 said: > > “ > > As can be seen above, all valid identifiers for YANG semantic version > > are valid in the file name as well. Section 4.3 of > > [I-D.ietf-netmod-yang-semver]” > > I think the second sentence seems not following the first sentence. > > s/ Section 4.3 of[I-D.ietf-netmod-yang-semver]”/ see more details in Section > 4.3 of[I-D.ietf-netmod-yang-semver]” Clarified that further details for YANG Semver identifiers are in Section 4.3 of [I-D.ietf-netmod-yang-semver]. > 3. Child Module Definition: > > Section 2.1 said: > > “ > > One consequence of this is that there might exist two child modules > > of version 2.0.0 with the same X.Y.Z digits (2.0.1) but different > > version labels: > > > > ” > > Where is the child module defined? I search this term from RFC7950 and > RFC9907 and i-d.ietf-netmod-yang-semver and can not find it. > > In my understanding, one new version of YANG Module X will be child module of > the current version of YANG Module X. > > The current version of YANG Module X will be child module of the previous > version of YANG Module X. This is made more clear with the branching trees that are presented in the YANG Semver document. I changed the wording a bit to show their inherit relation to the module 2.0.0. What do you think about the following, is it more clear? NEW: One consequence of this is that there might exist two modules derived from version 2.0.0 with the same X.Y.Z digits (2.0.1) but different version labels: > One thing is not clear is > > Suppose we use revision date for YANG Module X and we have made several > revisions before moving this module related work for publication, all these > revisions are Backwards-Compatible to each other, > > Do you think we still think one version of Module X will be the child module > of another version of Module X? > > > > 4. Section 2.2 Known Incompatibilities > > It seems Section 2.2 is all about implementation status, Do we really want to > keep them in the normative part of draft-ietf-netmod-yang-module-filename. > > Moving to Appendix? Moved it to append per your suggestion. Thanks! -- Per > > > -Qin > > 发件人: Mahesh Jethanandani [mailto:[email protected]] > 发送时间: 2026年4月22日 6:14 > 收件人: Joe Clarke (jclarke) <[email protected]> > 抄送: [email protected] > 主题: [netmod] Re: I-D Action: draft-ietf-netmod-yang-module-filename-08.txt > > > > I know I said I would like to move forward, but I realize that this change is > something we need to get WG feedback/consensus on. > > > > Lou/Kent, can I request a short WGLC (one week?) to make sure there are no > concerns or objections to this change? That will also allow Joe to make the > change in the tools. > > > > Thanks > > > > On Apr 16, 2026, at 6:31 AM, Joe Clarke (jclarke) <[email protected]> wrote: > > > > Not yet. The idea was to get WG feedback first. If consensus on overloading > ‘@‘, then xym needs to change as the support for ‘#’ has already been > upstream’d. I’ll have to change my local fork of rfcstrip, too. Ultimately, > libyang and pyang should have code to sanity check the filenames for a proper > date/YANG Semver. They do not today. > > > > Joe > > > > From: Mahesh Jethanandani <[email protected]> > Date: Wednesday, April 15, 2026 at 14:30 > To: Per Andersson <[email protected]> > Cc: [email protected] <[email protected]> > Subject: [netmod] Re: I-D Action: > draft-ietf-netmod-yang-module-filename-08.txt > > Hi Per, > > > > Thanks for what I hope will be a simplification of the change. Has the > tooling change been made to accommodate the change? > > > > Cheers. > > > > On Apr 15, 2026, at 2:07 AM, Per Andersson <[email protected]> wrote: > > > > Dear WG, > > The YANG Versioning Design Team has come to the > conclusion to not introduce another delimiter (the > number sign, "#") for the YANG Semver versioning > scheme in the YANG module filename convention, > but instead reuse the existing delimiter (at sign, "@"). > Strings from either versioning convention will never > match so it will trivial for tooling to infer version > convention used, for humans it is easy to visually > identify either versioning scheme as well. > > The motivation is to simplify operations and to not > introduce unnecessary turbulence for tools. > > This also better aligns with points made in LC reviews > from directorates and IANA. > > > -- > Per > > > On Wed, Apr 15, 2026 at 11:02 AM <[email protected]> wrote: > > > Internet-Draft draft-ietf-netmod-yang-module-filename-08.txt is now available. > It is a work item of the Network Modeling (NETMOD) WG of the IETF. > > Title: YANG module file name convention > Author: Per Andersson > Name: draft-ietf-netmod-yang-module-filename-08.txt > Pages: 6 > Dates: 2026-04-15 > > Abstract: > > This document presents YANG module file name convention. The > convention extends the current YANG module file name using > revision-date, with the YANG semantic version extension. The YANG > semantic version extension allows for an informative version to be > associated with a particular YANG module revision. > > This documents updates RFCs 6020, 7950, and > draft-ietf-netmod-rfc8407bis. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-netmod-yang-module-filename-08.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-module-filename-08 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > > Mahesh Jethanandani > > [email protected] > > > > > > > > > > > > > > > Mahesh Jethanandani > > [email protected] > > > > > > > > > > > > _______________________________________________ > netmod mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
