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. 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? 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. 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? ------------------------------------------------------------------------------- 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 Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
