Rob: Thank you for this note. It gives me a lot to think about.
Perhaps I can join a versioning meeting in the New Year. Sue Hares From: Rob Wilton (rwilton) <[email protected]> Sent: Tuesday, December 16, 2025 4:22 AM To: Susan Hares <[email protected]>; NETMOD WG <[email protected]> Subject: Re: YANG Versioning Work Hi Sue, I think that we are only look at this from a data model perspective for configuring devices and returning operational data rather than bindings to protocol specifications. We are not specifica External ([email protected]<mailto:[email protected]>) Report This Email<removed-link> Hi Sue, I think that we are only look at this from a data model perspective for configuring devices and returning operational data rather than bindings to protocol specifications. We are not specifically looking at these models or linkage of the models to the protocol specifications. Generally, I would expect that the data models that are defined for BGP Flowspec would: * Include a leaf or choice to allow the appropriate configuration to be expressed based on which version/sub-version of the protocol is being used, along with must, when or feature statements to enforce the constraints. * Generally, I don't think that data nodes should change meaning based on the protocol version, instead it better if different data nodes be used to expressed different meaning, and a combined data model is used that covers the known versions. * A single model could allow different protocol versions to be configured, or returned operationally, depending on which version of the BGP Flowspec is being used (again using choice/when/must statements) * I don't think that YANG version numbers should be used to try and to tie versions of the data model to different versions of BGP Flowspec * YANG packages would allow particular features to be enforced for a given package version, so if that was the mechanism used to separate behaviour that may work quite well. But nothing exists for asserting particular config must be set, or certain defaults be applied. I would be hesitant to add this at this stage to avoid ending up with an overly complex solution. Thanking about this some more, even using YANG Packages I don't think that this would compose well. So, I think that this solution still needs to be with how these different version nuances are modelled in the YANG data nodes. Happy to discuss further in one of the weekly meetings if that is helpful. Kind regards, Rob From: Susan Hares <[email protected]<mailto:[email protected]>> Date: Wednesday, 10 December 2025 at 19:50 To: NETMOD WG <[email protected]<mailto:[email protected]>> Subject: [netmod] Re: YANG Versioning Work Rob: Thank you for publishing the Yang versioning work update. It is a good step forward. Will this group consider issues related to BGP model linkage and BGP protocol changes? An example of this problem is: 1) Version 1 of BGP Flow Specification had multiple RFC revisions. Multiple revisions may be running in the network at one time. 2) Version 2 of BGP Flow Specification may also be running in a network with different RFC revisions. The monitoring device needs to be configured based on the version and sub-version, and the monitoring needs to be tailored accordingly. If you are not examining this problem, then please just let me know. If you think the problem is solved, please kindly educate me offline. Cheerily, Sue Hares ([email protected]<mailto:[email protected]>) From: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Sent: Tuesday, December 9, 2025 10:59 AM To: NETMOD WG <[email protected]<mailto:[email protected]>> Subject: [netmod] YANG Versioning Work HI NETMOD, During NETMOD at IETF 124, if was pointed out that we are happy to have extra folks help with the versioning work. We meet every Tuesday, and I've just forwarded the calendar invite to the WG. If you are interested, you are welcome to join us. I think that we will meet on Tuesday 16th Dec but then will take a few weeks off over the holiday period. In terms of current doc/work status: * The module version, filename, and Semver drafts are done from a WG perspective, and are now with the AD/IESG, so these don't require any extra help. * We are currently working on some updated IANA guidelines and YANG packages. I think that the packages draft is getting much closer to being finished. * There is a potential draft related to how YANG packages should be used in the IETF (that I have started but it is still in a very each stage at the moment), this work may get deferred further down the queue. * Per and Michal are actively working on the schema comparison document (backed by an implementation), and this seems to be progressing well. * But there is also the schema selection document, https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-ver-selection/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFjEESwiAQBL-S4iwhaFiIJ7-C7MakkoAFq5Za_l05ee2e6be45VUcGzExX8tRKfTsOfuwUG5n4rFN-aIwBYXZjywrkpF4SyifPl7knbIstFLgOUUldo1Yau43-R11ZxwMeq_K5DOVU8TX1Ia0KaTedB4c4NmRtiN666wGE3oLAGSVtmCchaHft3pwh4OpZarl_JhXTvEU5hJSjVWD1fzJ5wvgo0NK.MEQCIGJ1OjAr3wd2zZGt6crCd8t05p6UqH4Xt1SYdlBckyGQAiA6ZBDg6gHxpzs7k-HoAZee7azFBTg6UaI2or8pPzDawQ>, that is needed as part of the solution but doesn't have anyone actively working on this at the moment. There seems to be less energy amongst vendors to implement this draft. I think that some of us will go back to this after YANG packages work has completed, probably with an effort to simplify the solution as much as possible. If anyone is particularly interested in helping on this draft then that might be particularly helpful. Kind regards, Rob
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
