Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt

[Qin Wu <[e-mail]>]

Good input, Balazs, see my comments inline.

发件人: Balazs Lengyel [mailto:[e-mail]]
发送时间: 2018年10月8日 23:55
收件人: Qin Wu; Netconf
主题: Re: [Netconf] I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt


Hello,

1)  The function needs to support devices that have a factory reset functionality, but which are not capable to show the actual default values as a full datastore. Not all YANG servers will be full featured, big machines.

[Qin]: This can be resolved by introducing a new factory datastore, with existing operation, we can be able to know what contents are included in such datastore.

2) We have a number of writable datastores: running, startup, candidate, dynamic-datastores.  We need to document what happens with each. After reseting a datastore in the normal case

  1.  the running datastore is reset to mirror the content of the factory-default-datastore

[Qin]: you missed intended, can intended also be reset to mirror the content of the factory-default-datastore?

  1.  candidate datastore is reset to the same state as if the <discard-changes> operation was executed
  2.  startup datastore is reset to the same state as if <copy-config>  running->startup was executed
  3.  Any dynamic datastores are reset to empty

The system MAY provide YANG-Instance-Data based or other implementation specific documentation to specify other content that a datastore will have after a reset operation.

[Qin]: yeah, additional new supported module can be specified by using YANG-Instance-data documentation.

I wrote an example YANG module that could describe the above:

----------------------------

module ietf-factory-reset {

    namespace urn:ietf:params:xml:ns:yang:ietf-factory-reset ;

    prefix fres ;

    yang-version 1.1;



    import ietf-netconf { prefix nc ; }

    import ietf-datastores { prefix ds; }



    feature factory-default-as-datastore {

        description "Indicates that the factory default configuration is

            also available as a separate datastore";

    }



    rpc reset-datastore {

        description "The target datastore is reset to it's factory

            default content. The server MUST allow reset for the running

            datastore and MAY allow reset for any other writable datastore.";



        input {

            choice target-datastore {

                leaf target {

                    type identityref { base "ds:datastore" ; }

                }

                leaf all-datastores {

                    type empty;

                    description "All writable datastores including running,

                        startup, candidate and any dynamic datastores that exist

                        are reset to their default value.";

                }

            }



            // Do we need an extra parameter that may order a restart of

            // the YANG-server or the whole system?

        }

    }

[Qin]: Sounds good proposal,in my earlier version of draft, I defines an extra parameter to indicate whether restart is needed.

           If such parameter is needed, we can define it as empty type.



    identity factory-default-running-datastore {

        description "The read-only datastore contains the configuration that

            will be copied into the running datastore by the reset-datastore

            operation if the target is the running datastore.";

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

    }



    augment /nc:copy-config/nc:input/nc:target/nc:config-target {

        description " Allows the copy-config operation to use the

            factory-default-running-datastore as a source";

        if-feature factory-default-as-datastore;

        leaf factory-default { type empty ;}

}

      [Qin]: So in this case, we don’t need to define capability identifier. Instead, we are using feature to indicate whether a new functionality is needed, right?

}



regards Balazs
On 2018. 10. 08. 11:51, Juergen Schoenwaelder wrote:

On Mon, Oct 08, 2018 at 09:36:08AM +0000, Qin Wu wrote:



The content of factory is related to all configuration datastore, if

the content of factory need to be related to operational datastore

as well, a separate factory datastore is needed, in my opinion.



This is too vague and does not help me. You need to explain what the

data flow is between other datastores.



I am talking about copy-config, not get-config, do you suggest to

define copy-datastore new operation? If the answer is yes, I will

agree the capability identifier is not needed.



If we need a better copy-config, we should create a better copy-config

instead of introducing multiple ways to refer to datastores. I know

that early versions of draft-ietf-netconf-nmda-netconf-06 mentioned

copy-config, I need to dig deeper why this was taken out at some point

in time.



/js



--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: [phone]              email: [e-mail]<mailto:[e-mail]>