Hi Per, All good, especially the last part about marking that Appendix section to be removed by the RFC Editor.
Thanks, Kent > On Apr 28, 2026, at 12:47 PM, Per Andersson <[email protected]> wrote: > > 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] _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
