On Mon, Nov 29, 2021 at 3:49 PM Jürgen Schönwälder < j.schoenwael...@jacobs-university.de> wrote:
> On Mon, Nov 29, 2021 at 03:14:06PM -0800, Andy Bierman wrote: > > > > IMO the least disruptive solution possible should be used. > > There is a use-case for adding "origin" support to the <running> > datastore > > in the <get-data> operation. > > This allows an NMDA client to identify system config that is not being > used > > in <operational>. > > > > Looking at Figure 2 of RFC 8342, I wonder how system config gets into > running - other than a client writing it into running, at which point > the config becomes explicit config subject to the usual update rules > of <running>. Conceptually, you can have a system daemon acting as a > client updating <running> (perhaps even controllable by NACM). The > "origin" was not designed to track from which application config data > in <running> is originating, that's to be solved by other mechanisms. > > I see your point about the intent of "origin". The I2RS "owner" concept is different. The usage of the <running> config to contain both system and client data nodes goes back many decades in some cases. Usually the client data cannot even exist without the system ancestor nodes, so not sure how <running> would even work with client-only data. The more different the solution is from current practice, the less likely it will get adopted, unless it solves an important real problem. I am not sure there is an operational problem being solved here. I agree the system is just another client (exactly how our server is implemented), so why does it need special tracking and control at all? Why does any client get (or need) to inspect the edits of another client before they are made, and control how and when the edits are added? /js > Andy > > -- > 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
