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

From: Qin Wu <[email-masked]>
Date: Fri, 17 May 2019 10:54:05 +0000

v-01 is posted to address comments we have been discussed during the second adoption call.
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-01
The main changes include:
1.Change YANG server into server defined in NMDA architecture based on discussion.
2.Allow reset the content of all read-write configuration datastores to its factory-default content.
3.Add clarification text on factory-reset protocol operation behavior.

-Qin(on behalf of authors)
-----邮件原件-----
发件人: I-D-Announce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2019年5月17日 18:49
收件人: [email-masked]
抄送: [email-masked]
主题: I-D Action: draft-ietf-netmod-factory-default-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Factory Default Setting
        Authors         : Qin Wu
                          Balazs Lengyel
                          Ye Niu
	Filename        : draft-ietf-netmod-factory-default-01.txt
	Pages           : 11
	Date            : 2019-05-17

Abstract:
   This document defines a method to reset a server to its factory-
   default content.  The reset operation may be used e.g. during initial
   zero-touch configuration or when the existing configuration has major
   errors, so re-starting the configuration process from scratch is the
   best option.

   A new factory-reset RPC is defined.  Several methods of documenting
   the factory-default content are specified.

   Optionally a new "factory-default" read-only datastore is defined,
   that contains the data that will be copied over to the running
   datastore at reset.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-factory-default-01
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-01

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 May 2019 13:14:57 +0200

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.

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 copyright year needs adjustment. Indentation of the YANG
statements should be fixed.

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 May 2019 10:37:16 -0700

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

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

> statements should be fixed.
Andy

> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>