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

[Qin Wu <[e-mail]>]

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:[e-mail]] 代表 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>

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

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

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



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.

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

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.

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

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

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

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;
      }
   }
[Qin]: Good input, we will how to add this. Thanks.

Andy