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

[Juergen Schoenwaelder <[e-mail]>]

+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 <[e-mail]> On Behalf Of Juergen Schoenwaelder
> > Sent: 20 May 2019 07:20
> > To: Qin Wu <[e-mail]>
> > Cc: [e-mail]
> > 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:[e-mail]]
> > > 发送时间: 2019年5月17日 19:15
> > > 收件人: Qin Wu <[e-mail]>
> > > 抄送: [e-mail]
> > > 主题: 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>