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

[Kent Watsen <[e-mail]>]

The <copy-config> value-proposition is limited and not worth special effort to make happen.
  - RFC 6241: augment statements are needed to add to the existing RPCs, so just support
                       <get-config>.
  - RFC 8040: datastore aren't supported,  there's no way to access the "factory-default" datastore.
  - RFC 8342: Appendix A needs to be observed, which this draft does in its Section 3 (note, a
                       reference to Appendix A should be added here).
  - RFC 8526's <get-data> and <edit-data> come along for free (though edits would fail due to this
          new datastore being read-only.  Note that RFC 8526 does not define a <copy-data> RFC...
  - RFC 8527's datastore resource (i.e., /ds/ietf-datastores:operational:factory-default) and all the
          standard HTTP operations (OPTIONS, HEAD, GET, etc.)  come for free but, again, there is
          no "COPY" operation

Just supporting <get-config> (and not <copy-config>) is the most consistent option.

PS: the "WG Chair" lines should be removed from he YANG module.  We don't do that anymore.

Kent // contributor


> On May 20, 2019, at 6:31 AM, Juergen Schoenwaelder <[e-mail]> wrote:
> 
> +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/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod