Hi Jan,
Thanks again for your review. In rev-14 we have added a couple of "tougher
examples" as we discussed at IETF123, i.e. examples where the changes can not
be made gradually and a breaking (NBC) change has to be made immediately. This
is in Appendix C.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-14
Regards,Reshad.
On Friday, July 11, 2025 at 06:22:07 AM EDT, Jan Lindblad
<[email protected]> 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).
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.
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.
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.
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.
So more examples are needed, and more recommendations in added and existing use
cases, imho.
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 -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
