Jan, et. al, This discussion is timely. So, thanks.
> On Jul 11, 2025, at 3:21 AM, Jan Lindblad <jan.lindblad+i...@for.eco> wrote: > > Hi all, > > I had a thorough read through of draft-ietf-netmod-yang-module-versioning-13 > last week, and I agree with Xufeng that the document is in good shape (but I > may be biased, as I have been contributing somewhat to this work). Thanks for your contributions. Authors, please update Jan’s contact information. > > The only comment I have is on Appendix B, which contains a handful of use > case examples of how to apply the YANG versioning. In my opinion these > examples are central for readers to properly understand what's a good idea > and not. Currently, they are a bit too defensive, only showing really simple > cases and not trying to give any guidance on what to do in some harder real > world cases. While it may be hard to prescribe exactly what MUST happen in > some of these cases, the document -- and the community -- would benefit > greatly from more and better descriptions of what should ideally happen. Can you suggest how the examples could be more bold? 😀 > > Specifics: Example B2 talks about changing a leaf "vpn-id". In my world a > leaf named like that would typically be a key, and if so could not be treated > as described. Let us take the example as is, and let us say that for some reason, the need was to change the name and type of the key, similar to example B4. What would be your recommendation, both with what the change should be, and how versioning should capture it? Same as B4 with an additional leaf to indicate which list to use? What happens after one year to the obsoleted list, and the new leaf that selects the list? Or a completely different solution that does not involve a duplicate list? > > I think it would be great if the examples stated that ideally the sequence > <get-config> + change one leaf + <edit-config> should work for all leafs, old > as well as newly added. And that get-config should ideally only return one of > them. I am not sure I understand the last statement. Can you explain what you mean by “only return one of them”? > > Example B4, assuming it is talking about a config true scenario (the example > doesn't say, even though this is crucial for the use case), having both lists > supported at the same time will be highly problematic. The example should say > so, and maybe there should be a config leaf selecting which style of > representation is used? > > Example B5 point 3 is ducking from the important points by stating out of > scope when it comes to how servers should behave. Recommendations in this > area are critical for interoperability. How would your recommendation differ from what is stated in 3? > > So more examples are needed, and more recommendations in added and existing > use cases, imho. More examples are always helpful. Maybe you can suggest what those examples should cover. Cheers. > > Best Regards, > /jan > > >> Document: draft-ietf-netmod-yang-module-versioning >> Title: Updated YANG Module Revision Handling >> Reviewer: Xufeng Liu >> Review result: Ready >> >> This is a review of the YANG modules in >> draft-ietf-netmod-yang-module-versioning-13. >> >> This document contains two simple YANG modules: ietf-yang-revisions and >> ietf-yang-library-status, which are clearly defined. >> >> 1) Data examples >> The module ietf-yang-library-status has added only two leaves. Even though >> the >> augmentation is simple, I am still wondering if it would be beneficial to >> provide a data example in the Appedix >> >> 2) Both ietf-yang-revisions and ietf-yang-library-status are defined in >> Section >> 7 “Module Versioning Extension YANG Modules”. Should ietf-yang-library-status >> be put into a different section? >> >> Thanks, >> - Xufeng >> >> >> >> _______________________________________________ >> netmod mailing list -- netmod@ietf.org >> To unsubscribe send an email to netmod-le...@ietf.org Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
