Re: [netmod] YANG Versioning: filename recommendations for YANG Semver
Hi, On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) wrote: > > > > > *From: *Andy Bierman > *Date: *Tuesday, April 2, 2024 at 17:40 > *To: *Joe Clarke (jclarke) > *Cc: *Jason Sterne (Nokia) , > netmod@ietf.org > *Subject: *Re: [netmod] YANG Versioning: filename recommendations for > YANG Semver > > > > > > On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) > wrote: > > Thanks, Andy. See inline below. > > > > I do not agree with these recommendations to change the file names of YANG > modules. > > The OFFICIAL YANG version is RFC 7950 - YANG 1.1. > > Any module using YANG version 1.1 needs to follow the rules in RFC 7950. > > Additional file naming that can be ignored by YANG 1.1 tools is OK. > > > > [JMC] We had this conversation on our call today. I agree with you that > tools can be unaware of YANG Semver and attempt to load a file named > foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the > module name defined within the module. > > > > > > This can never happen since the '#' char is not allowed in a YANG module > name. > > YANG 1.1 tools look for MODNAME[@DATE].EXT. > > If the YANG module name is not in this format the tool will not find the > module. > > > > [JMC] Of course. We (authors on the call) were debating what a tool would > do with the *filename* if it didn’t understand this YANG Semver naming. > > > > The issue is obviously not the 2 lines of code to parse "#" instead of "@". > > IMO this file name change is operationally disruptive and not really > needed. > > How come OpenConfig modules do not use this naming scheme? > > Is it because they are following the RFC 7950 file naming rules? > > > > [JMC] This naming scheme hadn’t been introduced. OpenConfig doesn’t use > the @ convention, either. They just have naked module names from what I > can see (https://github.com/openconfig/public/tree/master/release/models). > I know that at least one vendor is already using YANG Semver and the ‘#’ > notation for file naming. I believe it is in part because of this the > chairs wanted us to revisit the naming. > > > > > > So the revision-date is the only field that can be relied upon since the > same SemVer (e.g. "1.0.0") could be released several times, > > each one containing different content. > > > > [JMC] Just as with revision-date, the YANG Semver identifier must be > unique. You cannot have multiple “1.0.0” identifiers for the same module > with different content. That 1.0.0 would be tied to a revision of a unique > date. > > > I do not see any net value by changing the filename spec so it is different than YANG 1.1. Duplication of files is a bug, not a feature. Tools usually rely on a proprietary search path configuration to find modules. Some clients rely on and always use the modules from the server. This is stable and has been the practice since 2016. IMO this is an NBC change to YANG 1.1, so it should not be done at all. Adding YANG extensions is fine, and I support that part of this work. Joe > > > Andy > > > Joe > > > > > > Andy > > > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG Versioning: filename recommendations for YANG Semver
> This can never happen since the '#' char is not allowed in a YANG module name. > YANG 1.1 tools look for MODNAME[@DATE].EXT. > If the YANG module name is not in this format the tool will not find the > module. https://datatracker.ietf.org/doc/html/rfc7950#section-5.2 says: The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) The “SHOULD” (I believe) leaves open (process-wise) the possibility for an “update” to RFC 7950 to define an alternate file naming possibility. Whether or how doing so is wise is a different conversation. Kent___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] YANG Versioning: filename recommendations for YANG Semver
From: Andy Bierman Date: Tuesday, April 2, 2024 at 17:40 To: Joe Clarke (jclarke) Cc: Jason Sterne (Nokia) , netmod@ietf.org Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) mailto:jcla...@cisco.com>> wrote: Thanks, Andy. See inline below. I do not agree with these recommendations to change the file names of YANG modules. The OFFICIAL YANG version is RFC 7950 - YANG 1.1. Any module using YANG version 1.1 needs to follow the rules in RFC 7950. Additional file naming that can be ignored by YANG 1.1 tools is OK. [JMC] We had this conversation on our call today. I agree with you that tools can be unaware of YANG Semver and attempt to load a file named foo#1.2.3.yang as a module named “foo#1.2.3”, which would disagree with the module name defined within the module. This can never happen since the '#' char is not allowed in a YANG module name. YANG 1.1 tools look for MODNAME[@DATE].EXT. If the YANG module name is not in this format the tool will not find the module. [JMC] Of course. We (authors on the call) were debating what a tool would do with the filename if it didn’t understand this YANG Semver naming. The issue is obviously not the 2 lines of code to parse "#" instead of "@". IMO this file name change is operationally disruptive and not really needed. How come OpenConfig modules do not use this naming scheme? Is it because they are following the RFC 7950 file naming rules? [JMC] This naming scheme hadn’t been introduced. OpenConfig doesn’t use the @ convention, either. They just have naked module names from what I can see (https://github.com/openconfig/public/tree/master/release/models). I know that at least one vendor is already using YANG Semver and the ‘#’ notation for file naming. I believe it is in part because of this the chairs wanted us to revisit the naming. So the revision-date is the only field that can be relied upon since the same SemVer (e.g. "1.0.0") could be released several times, each one containing different content. [JMC] Just as with revision-date, the YANG Semver identifier must be unique. You cannot have multiple “1.0.0” identifiers for the same module with different content. That 1.0.0 would be tied to a revision of a unique date. Joe Joe Andy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
