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
> <[email protected]> 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 <[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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
