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

[Andy Bierman <[e-mail]>]

On Fri, May 17, 2019 at 4:15 AM Juergen Schoenwaelder <
[e-mail]> wrote:

> 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.
>
>
Agreed. I have been objecting to the client-controlled datastore-specific
factory reset.
I do not know of any devices which support such a thing.  I would like to
understand the use-cases that make this so useful and common practice that
it
should be standardized.



> 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?
>
>    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?
>
>
The startup procedure within a server is very proprietary and can be
very different, even for vendors using the same server code.

There are no standard procedures today that allow a client to inject
configuration
into this process. The client is allowed to alter configuration only after
the saved or factory configuration is loaded.  IMO it should stay this way.

e.g, : do not want to standardize:

   copy-config source=factory target=candidate
   edit-config target=candidate ...
   commit

This is the only use-case I can imagine for copy-config from factory,
but IMO it is not very important. (get-config(factory) + edit-config
already supports it.)


The copyright year needs adjustment. Indentation of the YANG
> statements should be fixed.
>
> /js
>
>
Andy


> --
> 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
>