Hi Andy, Thanks for the comments. We discussed this last week in our weekly meeting and agreed that a short experimental RFC covering just the filename might be a good way forward.
To respond to your technical concern, I think that ‘#’ should be fine in XML, JSON and YAML without quoting (YAML shouldn’t treat it is as comment if it isn’t directly preceded by a space). Python would need it to be quoted. I.e., I still think that this is likely to be a reasonable approach? Lou, I think that it was you who raised this issue at IETF 119. Are you okay with the proposal to move this to a separate experimental draft to unblock taking the module versioning draft to last call? Regards, Rob From: Andy Bierman <[email protected]> Date: Wednesday, 10 April 2024 at 22:11 To: Rob Wilton (rwilton) <[email protected]> Cc: Jason Sterne (Nokia) <[email protected]>, [email protected] <[email protected]>, Joe Clarke (jclarke) <[email protected]> Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver On Tue, Apr 9, 2024 at 7:01 AM Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> wrote: Hi Andy, For me, it seems likely that vendors using YANG Semver will want to use a filename that can contain the Semver label, and I still see some advantages for everyone to do it in a similar way. E.g., it is very likely that internally we will just use this format, but will probably strip or convert it before publishing them. But I agree that we shouldn’t formally change the filename format in YANG 1.1, and that would be best left for YANG 2.0 (obviously if agreed at that time). My question is whether we can find some middle ground where we at least informally document the format in an appendix now (i.e., as non-normative text), so that if folks are starting to use a format, then they could choose this one, but not to change the extension representation/API when naming YANG modules. Such an appendix might start with something like: <start proposal> “During this work it was discussed that having a filename format that allows for the Semver, rather than the revision-date to be expressed in the filename, would be beneficial. It was concluded that making such a change would risk breaking existing tooling and hence would be better deferred to a further revision of the YANG language. The proposed format is ‘informatively’ documented below, which might be adopted in a future revision of YANG. … <include the definition that we had before but with no RFC 2119 keywords> <end proposal> Would such an approach potentially be acceptable to you? Or are you strongly against saying anything at all? Note the motivation for considering put this in is because a comment was raised during IETF 119 about avoiding an undocumented de facto standard – I would like to get consensus on this draft so that we can get it published an move on. I tried 3 YANG compilers on a filename with the extension and it caused a warning in 2 of them and no problem at all in the other. However, the '#' character is used in config files to mean 'comment to end of line', so this syntax would be a problem. The "module-name@revision-date" pattern is used by several tools already. I don't think changing the file-naming convention for YANG 1.1 is a good idea. It should be in a separate Experimental RFC. Regards, Rob Andy From: netmod <[email protected]<mailto:[email protected]>> on behalf of Andy Bierman <[email protected]<mailto:[email protected]>> Date: Wednesday, 3 April 2024 at 19:07 To: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> Cc: Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver Hi, On Wed, Apr 3, 2024 at 10:34 AM Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> wrote: From: Andy Bierman <[email protected]<mailto:[email protected]>> Date: Tuesday, April 2, 2024 at 17:40 To: Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> Cc: Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [netmod] YANG Versioning: filename recommendations for YANG Semver On Tue, Apr 2, 2024 at 2:11 PM Joe Clarke (jclarke) <[email protected]<mailto:[email protected]>> 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 <get-schema> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
