发件人: Andy Bierman [mailto:[email protected]] 发送时间: 2019年5月18日 1:37 收件人: Juergen Schoenwaelder <[email protected]>; Qin Wu <[email protected]>; [email protected] 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
On Fri, May 17, 2019 at 4:15 AM Juergen Schoenwaelder <[email protected]<mailto:[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. [Qin]:There is misunderstanding on the last sentence of the quoted text. I will fix this. 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.) [Qin]:Not sure I understand the <startup> can not be intervened. For writable running, we should allow copy-config operation copy the content to <running> We should also allow copy config operation copy the content from <running> to <startup> See the second figure in the following link: http://www.netconfcentral.org/netconf_docs 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
