On Wed, Aug 4, 2021 at 5:34 AM Kent Watsen <[email protected]> wrote: > > I am confused by the confusion ;) > > You all know that JUNOS implemented this concept before YANG was even a > thing, right? > > Admittedly, it’s not a “datastore“, but flexing the NMDA is where we can > do better. > > A “with-system” mechanism could also work. The only downside is the > inability for a client to get only the system configuration, without the > rest of <running>. > > Please stop stating/suggesting “config true” nodes are referencing “config > false” nodes, or that config is referencing operational state. There is > no intention to break either of these tenants here. > > I think that some folks just joined the conversation and may have missed > out when we covered all this before. > > The draft needs to be updated to more clearly identify the goals.
I strongly agree the draft could better explain the problem and the value of the solution, especially how this datastore is used to represent system values that are not in use. Since NMDA already provides a solution to retrieve the "system-only" nodes that are in use, there is no value in that part of the system datastore at all. Also some pointers to implementations of this system datastore would be helpful. I am confused because there was an assertion made that this system datastore was needed so that the nodes could be referenced in config XPath. This is not correct. The solution that Balazs outlined is quite common and much better and less disruptive than adding a new datastore. It is trivial to identify the user-write operations that are allowed (e.g. modify but not create, delete, or rename a physical interface). > > K. > > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
