Subject: [Netconf] comments on draft-wu-netconf-restconf-factory-restore-03

From: Andy Bierman <[email-masked]>
Date: Sun, 2 Dec 2018 10:02:57 -0800

Hi,

I have comments and questions on the functional requirements and
scope of the problem(s) to be solved. Scope seem to be:
   G1) reset device to factory config
   G2) set any datastore to contents of the factory config with
<copy-config>
   G3) retrieve contents of factory-config with <get-data>

Q1) what is the factory datastore?

The concept of a factory default config is universal but the implementation
is not.
This needs to be precisely defined in the draft.

There is actually a factory-startup (--> running) and factory-intended.
By default the factory-startup is likely an empty config (i.e. just the
YANG defaults
supported by the server).  The factory-intended is implementation-specific.

So what is standardized? factory-startup or factory-intended? both?

Q2) leaf-list of datastores to reset

Setting specific datastores to factory default is complex and dangerous.
It is unlikely a server will support all possible combinations.
A simple RPC to return the entire server to factory default is much easier
to use
and implement. Vendors can add input parameters to support their variants.

Q3) filtered retrieval of the factory settings

If a real datastore is used as proposed, then is subtree and XPath
filtering required?
It seems all operations except edit have to be supported by the server.

Q4) why no retrieval without NMDA, factory-default-as-datastore feature?

It would be useful to know what will happen if <reset-datastore> is invoked
by retrieving the contents of the factory config. This is not possible if
the datastore feature is not supported. I suggest another RPC

   rpc get-factory-defaults {
      if-feature "not factory-default-as-datastore";
      output {
        anydata data;
      }
   }

Andy

---

From: Qin Wu <[email-masked]>
Date: Wed, 5 Dec 2018 09:25:38 +0000

Thanks Andy.
This draft has been agreed to move to netmod based on discussion and replaced with
https://tools.ietf.org/html/draft-wu-netmod-factory-default-02
Please see my comments inline below.

发件人: Netconf [mailto:[email-masked]] 代表 Andy Bierman
发送时间: 2018年12月3日 2:03
收件人: Netconf
主题: [Netconf] comments on draft-wu-netconf-restconf-factory-restore-03

Hi,

I have comments and questions on the functional requirements and
scope of the problem(s) to be solved. Scope seem to be:
   G1) reset device to factory config
   G2) set any datastore to contents of the factory config with <copy-config>
            [Qin]: besides <copy-config>, you also can use new operation <reset-datastore> to set it to contents of the factory config.
   G3) retrieve contents of factory-config with <get-data>

The concept of a factory default config is universal but the implementation is not.
This needs to be precisely defined in the draft.
[Qin]: Yes, the definition has been provided in section 1.1.If there is any ambiguity, please let us know.

There is actually a factory-startup (--> running) and factory-intended.
By default the factory-startup is likely an empty config (i.e. just the YANG defaults
supported by the server).  The factory-intended is implementation-specific.

[Qin]: factory config content can be content of <running>,<startup>,<candidate>
As clarified in appendix B:
When the device first boots up, the content of the <startup> and
   <factory-default> will be identical.  The content of <startup> can be
   subsequently changed by using <startup> as a target in a <copy-
   config> operation.  The <factory-default> is a read-only datastore
   and it is usually static as described in earlier sections.

Setting specific datastores to factory default is complex and dangerous.
It is unlikely a server will support all possible combinations.
A simple RPC to return the entire server to factory default is much easier to use
and implement. Vendors can add input parameters to support their variants.

[Qin]: in most case, we just return entire server to factory default, however for dynamic config, we believe in most case it will be set to empty which is different from other datastore.
In earlier version, we consider to use choice case, allows default-allow-all case, if this address your comment, we can go with this.

If a real datastore is used as proposed, then is subtree and XPath filtering required?
It seems all operations except edit have to be supported by the server.

[Qin]:we can add subtree and xpath filter if more fine granularity operation is needed to deal with portion config of one datastore.
At the current version, <reset-datastore> is datastore level operation.

[Qin]: talking with Balazs, we think in some cases, <reset-datastore> operation can be used without <factory> datastore.

   rpc get-factory-defaults {
      if-feature "not factory-default-as-datastore";
      output {
        anydata data;
      }
   }
[Qin]: Good input, we will how to add this. Thanks.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Dec 2018 10:35:55 +0100

> In earlier version, we consider to use choice case, allows default-allow-all case, if this address your comment, we can go with this.

I guess I am with Andy here. Let the device decide what it takes to
restart the factory default. If there is a dynamic datastore that
needs to be cleared, the device will do this. Why would a management
application need to know the internals of a reset to factory defaults
operation?

>       if-feature "not factory-default-as-datastore";

I am generally not a big an of get-* and set-*/edit-* operations that
replicate something for which we already have a solution in place.

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