If the purpose of the extending the copy-config operation to the factory-default datastore is just another generic way to do the factory-reset RPC then I would suggest that we don't modify copy-config as part of this draft. Instead, I think that it would be good to fix this generically (for any datastore) in a future update of NETCONF - I see that you have already raised https://github.com/netconf-wg/netconf-next/issues/2 to track this.
In theory, a client could use copy-config in a slightly different way to the factory-reset RPC, i.e., to copy from the factory-default to candidate, then have the client modify the configuration until they are happy with it, before committing it. But I'm not sure that this in the best approach. If I was writing a client, I would choose to code the client to read from the factory-default datastore (if needed), then construct whatever the desired configuration of the device is, before pushing it to device. For me, I think that the most important parts of this draft are being able to read from the factory-default datastore, and having an RPC to reset the device back to the factory-default state. I would probably defer updating copy-config until it can be fixed properly in NETCONF. Thanks, Rob > -----Original Message----- > From: netmod <[email protected]> On Behalf Of Juergen Schoenwaelder > Sent: 20 May 2019 07:20 > To: Qin Wu <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt > > On Mon, May 20, 2019 at 05:57:02AM +0000, Qin Wu wrote: > > -----邮件原件----- > > 发件人: Juergen Schoenwaelder > > [mailto:[email protected]] > > 发送时间: 2019年5月17日 19:15 > > 收件人: Qin Wu <[email protected]> > > 抄送: [email protected] > > 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt > > > > 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. > > [Qin]:Automatic propagation we were referred to is that when we have > > three datastores, let's say datastore A, datastore B, datastore C, one > time <copy-config> operation can not copy content of datastore A to > datstore B and datastore C at the same time, But you are right, content of > <running> will be automatically propagated to <intended> and <operational>, > we will see how to tweak the text. > > This is not what the text says. And given the parameters of copy-config, it > is obvious that you can't copy to multiple datastores. > > > 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? > > [Qin]: Note that this is just an option feature to <copy-config> to > assign one single target datastore with factory default content, I am > wondering why it can not be defined in this draft in a more generic way? > > Even in RFC6241bis or a separate draft, if you add this feature support > to <copy-config>, you will augment <copy-config> in the same way, if my > understanding is correct. > > No. You would allow any datastore, not a specific one. > > > 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? > > [Qin]: We emphasize "usually not", to address your comments, we could > add: > > " > > When its contents are considered sensitive, It is RECOMMENDED that the > > factory default Data is encrypted." > > You propose to invent another layer of encryption??? > > /js > > -- > 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
