On Fri, May 17, 2019 at 4:15 AM Juergen Schoenwaelder < [email protected]> wrote:
> I think this does not work: > > [...] For <copy-config> operation,it can be used to copy > the factory default content to another datastore, however the > content of the datastore is not propagated automatically to any > other datastores. > > You can't change the way things work. If something is committed to > lets say <running>, then this triggers the propagation to <intended> > and eventually <operational>. You can't come along and say that > copy-config from a particular source stops this. > > Agreed. I have been objecting to the client-controlled datastore-specific factory reset. I do not know of any devices which support such a thing. I would like to understand the use-cases that make this so useful and common practice that it should be standardized. > Is it really useful to expose factory default to copy config? Or said > differenlty, would it not make sense to fix copy-config (at some other > place) so that it can generically work with new datastores? > > The content of the factory-default datastore is usually not security > sensitive as it is the same on any device of a certain type. > > I am not sure this is true. > > For non-trivial devices, the default is likely not static but > something that takes into account device features available and the > specific hardware configuration present. It is actually somewhat > unclear what the factory-default datastore contains; the stuff I can > expect to see in <running> after the reset or some static stuff that > may be tweaked during the boot process to yield the initial <running>. > Or are we pretending these two are always the same? > > The startup procedure within a server is very proprietary and can be very different, even for vendors using the same server code. There are no standard procedures today that allow a client to inject configuration into this process. The client is allowed to alter configuration only after the saved or factory configuration is loaded. IMO it should stay this way. e.g, : do not want to standardize: copy-config source=factory target=candidate edit-config target=candidate ... commit This is the only use-case I can imagine for copy-config from factory, but IMO it is not very important. (get-config(factory) + edit-config already supports it.) The copyright year needs adjustment. Indentation of the YANG > statements should be fixed. > > /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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
