Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt

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 <netmod-bounces@ietf.org> On Behalf Of Juergen Schoenwaelder
> Sent: 20 May 2019 07:20
> To: Qin Wu <bill.wu@huawei.com>
> Cc: netmod@ietf.org
> 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:j.schoenwaelder@jacobs-university.de]
> > 发送时间: 2019年5月17日 19:15
> > 收件人: Qin Wu <bill.wu@huawei.com>
> > 抄送: netmod@ietf.org
> > 主题: 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod