+1 /js
On Mon, May 20, 2019 at 09:53:35AM +0000, Rob Wilton (rwilton) wrote: > 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 -- 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
