The figure in RFC 8342 section 5 documents what was agreed upon before. System configuration flows into <operational> but not upwards into <running>. Over the years, we discussed several corner cases (including things like configuring a new user and the system automatically assigns an unused uid, which afterwards needs to be kept stable). While there are for sure tricky corner cases, I am not convinced that the model defined in RFC 8342 for the general cases is wrong and that merging a new system datastore into <running> is the right approach. If people want to change the model documented in RFC 8342, then they should make an explicit statement about this and provide strong reasons that the model is flawed or incomplete.
Note that the model does allow having a system client merging config into <running> (ideally controlled by an ACM so that such a client can be turned off if it leads to surprises). /js On Wed, Aug 04, 2021 at 12:34:45PM +0000, Kent Watsen 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. > > K. > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
