Hi Kent, Thanks for the review!
On Tue, Apr 28, 2026 at 4:23 PM Kent Watsen <[email protected]> wrote: > > [As a contributor, looking at Per's original message] > > Hi Per, > > > > > The motivation is to simplify operations and to not > > introduce unnecessary turbulence for tools. > > > Could you share more about how this simplifies > operations and reduces tool turbulence? It increases information conveyed about the lifecycle of YANG modules, whether they contain any NBC changes. Regarding tool turbulance, many tools might currently just ignore what is after the current @ delimiter and continue working. My experience is that the # delimiter is more disruptive, not many tools will accept it currently. Case in point, pyang 2.7.1 $ pyang [email protected] $ pyang foo#1.0.0.yang foo#1.0.0.yang:1: warning: filename "foo#1.0.0.yang" suggests invalid module name "foo#1.0.0", should match "[_A-Za-z][._\-A-Za-z0-9]*" > > This also better aligns with points made in LC reviews > > from directorates and IANA. > > > Searching the list archive, I see a message from Meir > Goldman on March 2nd regarding '#' being a URI > fragment delimiter. I suppose it is a valid concern, > e.g., for HTTP-based file retrieval, or in RESTCONF, > if a module's sem-ver name is used as a YANG list > key (not the case in YANG Library, RFC 8525). But > was there a test with IANA's web server, or any web > server? Where does this concern arise in practice, > or expected to arise? Is it server-side or client-side > concern? No test was done, but since # is the fragment identifier it needs to be percent encoded to not be interpreted as such. It would be both a client side and server side concerns. A redirect from a web server missing to percent encode the # will send to a client as a fragment identifier. However, a client would always need to percent encode the delimiting # in order to not use it as a fragment identifier. My guess is that this is probably not a large concern, but enough voices were raised in LC reviews and in the design team to warrant a change. > Were there any other LC reviews from directorates and > IANA related to this issue? The IANA review from David Dong [0] had the following note: IANA also has a concern about the proper encoding of an URI associated with the file name; for the example in the document, "example-module#2.3.1_non_compatible+build2237refM443ss.yang", the # character would be interpreted as an URL fragment identifier and not as part of the file name, so we would need to encode this properly in the relevant URL (https://www.iana.org/assignments/yang-parameters/example-module%232.3.1_non_compatible+build2237refM443ss.yang). [0] https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/history/ > PS: looking at the -05 to -10 diff, I see that the "Known > Incompatibilities" section was moved to Appendix A. > This is better, but I wonder if better still would be to > remove it entirely, or mark it as to be removed by the > Editor before publication. Does the information have > long-term value? BTW, "Known Incompatibilities" is > a misnomer, as the section doesn't actually identify > any incompatibilities. No, there probably is no reason to keep it. I'll mark it to be removed by the RFC Editor. -- Per > Kent > > > On Apr 27, 2026, at 6:31 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. > > Thank you, > > Kent and Lou > > [1] > https://author-tools.ietf.org/iddiff?url1=draft-ietf-netmod-yang-module-filename-05&url2=draft-ietf-netmod-yang-module-filename-10&difftype=--html > > -------- Forwarded Message -------- > Subject: Comment added to draft-ietf-netmod-yang-module-filename history > Date: Mon, 27 Apr 2026 08:33:39 -0700 > From: IETF Secretariat <[email protected]> > To: [email protected], [email protected], > [email protected], [email protected] > > > > Please DO NOT reply to this email. > > Mahesh Jethanandani added the following comment to the history of > draft-ietf-netmod-yang-module-filename > > The change to use @ in the filename for semver from # is a significant > change, and has come after WGLC. As such, I am requesting that the chairs run > a short WGLC, just on that change, of maybe a week, to make sure there are no > objections. > > The document can be found at > I-D: <draft-ietf-netmod-yang-module-filename-10.txt> > Datatracker URL: > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-filename/ > > > > > _______________________________________________ > 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]
