Hi Per, > On Aug 6, 2025, at 3:40 AM, Per Andersson <[email protected]> wrote: > > Hi Mahesh, > > Thank you for your review! Comments inline. > > > On Tue, Aug 5, 2025 at 9:47 PM Mahesh Jethanandani > <[email protected] <mailto:[email protected]>> wrote: >> >> >> Hi Per, >> >> Thanks for working on this document. While this review is particularly for >> this draft, the two other related drafts, draft-ietf-netmod-yang-semver and >> draft-ietf-netmod-yang-module-versioning, will be progressed along with this >> draft as a single cluster. >> >> Please find enclosed some comments that hopefully go towards improving the >> document. >> >> Abstract >> >> This document updates RFC6020, RFC7950, and RFC8407, but does not seem to >> include explanatory text about this in the abstract. > > It does contain > > This documents updates RFCs 6020, 7950, and 8407. > > As the second paragraph of the abstract.
My bad. I should have checked the draft, instead of the tool that flagged it as an error. We are good on this, and no more action is needed. > > I checked a dozen or so RFCs and this seems to be the common > mention of updates without any further explanation. > > Do you suggest an additional statement about the updates? Something > like: > > This document updates RFCs 6020, 7950, and 8407, to > allow files to use the YANG module versioning defined in > [I-D.ietf-netmod-yang-module-versioning] and > [I-D.ietf-netmod-yang-semver]. > > >> Section 1, paragraph 0 >>> This document defines the YANG module file convention. It extends >>> the current convention defined in [RFC6020], [RFC7950], and >>> [RFC8407], which uses revision-date, with the YANG semantic version >>> extension defined in [I-D.ietf-netmod-yang-semver]. >> >> Should this refer to rfc8407bis here? > > How will that work with the updates attribute for the document? > If this is changed to rfc8407bis, should the updates attribute > and the abstract also reference that it updates rfc8407bis? Yes, the update is to rfc8407bis. That might mean that this document will hit a MISSREF when it enters the RFC Editor queue, but it will clear once that document is published as an RFC (hopefully soon). > > >> Section 1.2, paragraph 1 >>> The YANG module file name schema described in this draft is already >>> deployed in the industry. Now is the time to standardize before >>> several proprietary solutions emerge. One possibility is to propose >>> a standard that gains operational experience. >>> >>> Experiments that have updated tooling to handle YANG semantic version >>> in the YANG module file name according to this draft have shown that >>> it is a relatively small effort to do so. However, it is recognized >>> that the migration of all tooling within the industry will take time. >> >> That might be true for a file name using YANG semantic version. However, >> that may not always be the case when all possible permutations of imports >> are done using 'recommended-min-version’, especially as it relates to >> branches that contain NBC changes. Moreover, some of the statements in these >> paragraphs can be best described as speculative. It is best to remove both >> these paragraphs. > > Will remove these paragraphs. > > >> Section 3, paragraph 1 >>> The registry SHOULD avoid publishing multiple instances of the same >>> YANG module with different file names. If this situation is >>> motivated, for instance due to maintaining backwards compatibility, >>> it can however be possible that the registry needs to publish the >>> same YANG module with multiple file names. For instance, if a YANG >>> module starts to use YANG SemVer, it might simplify for consumers to >>> publish this with filename and revision-date and also filename and >>> ysv:version. >> >> Unfortunately, this guidance to IANA is vague. They will need to be given >> clear guidance on what to expect. Should they publish the YANG module with >> multiple names or not? If they must publish multiple file names, should they >> exist in the same folder? > > I need some guidance here. What is it exactly that IANA > facilitates? A directory with YANG modules (files)? (The > YANG parameters registry?) If we are proposing that all YANG modules MUST use YANG semver going forward, it is odd that we are only recommending a MAY for creating a filename with semver. If we do not need a separate file to support YANG semver, why do we need this draft? It should either be a MUST (for creation of another filename), or we do not need it and thus do not need this draft. As I referred to in the other thread, IANA extracts ALL YANG modules to put them in the yang-parameters registry/folder. In addition, IANA based YANG modules are extracted from the document before it becomes RFC, and removes it from the document before publishing it as an RFC. Thereafter, it starts maintaining the module. As part of maintenance, if there is a change in the registry, IANA updates the modules, adds a new revision statement (date based), and publishes the module as a new module. Guidance for how to update the module w.r.t. YANG Semver has already been provided in the semver draft. However, that document does not talk about filenames. if the module is being published as two filenames, what is it expected to do with the second filename? Should it update the second file similarly? Separately, should IANA maintain the two filenames in the same folder or seprate folder? Similarly, users will need guidance on whether they should create one or two filenames when proposing a new YANG module. If xym or other tool can create that filename with all the annotations as part of extraction, then no new guidance is needed. However, users should be aware that the two filenames need to/will be generated. I know Joe offered to update xym, but I am not sure what all is in-scope of that change. Does this help? > > >> ------------------------------------------------------------------------------- >> NIT >> ------------------------------------------------------------------------------- >> >> All comments below are about very minor potential issues that you may choose >> to >> address in some way - or ignore - as you see fit. Some were flagged by >> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there >> will likely be some false positives. There is no need to let me know what you >> did with these suggestions. >> >> Section 1.2, paragraph 0 >>> The motivation for using YANG semantic version instead of revision >>> date is that it carries information to the user. A revision date >>> only tells the user that it has been updated, while, for instance, a >>> YANG SemVer version can tell the user about the module's >>> compatibility level at a glance. Having this information available >>> as early as possible, i.e. in the module file name, makes it possible >>> to quickly identify the module revision; compared to searching in the >>> file contents and checking the revisions. Having the YANG semantic >>> version visible in the file name will make it easier to handle large >>> sets of YANG modules. >> >> s/carries information to the user/carries additional information for the >> user/ > > Thanks! > > > -- > Per Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
