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

From: Qin Wu <[email-masked]>
Date: Sun, 30 Sep 2018 09:35:26 +0000

v-(02) has been posted to addressed comments discussion on the list.
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-wu-netconf-restconf-factory-restore-02
Your review and input are welcome.

-Qin
-----邮件原件-----
发件人: I-D-Announce [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2018年9月14日 18:28
收件人: [email-masked]
主题: I-D Action: draft-wu-netconf-restconf-factory-restore-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Factory default Setting Capability
        Authors         : Qin Wu
                          Ye Niu
	Filename        : draft-wu-netconf-restconf-factory-restore-02.txt
	Pages           : 11
	Date            : 2018-09-14

Abstract:
   This document defines capability based extension to NETCONF and
   RESTCONF protocol that allows a client to configure newly deployed
   devices with just its preconfigured initial state (i.e., factory
   default settings) during zero touch bootstrapping process or reset
   the device with the content of factory default setting configuration.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wu-netconf-restconf-factory-restore/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-wu-netconf-restconf-factory-restore-02
https://datatracker.ietf.org/doc/html/draft-wu-netconf-restconf-factory-restore-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wu-netconf-restconf-factory-restore-02

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: Sun, 30 Sep 2018 15:03:39 +0200

> Your review and input are welcome.

   This document introduces a new datastore resource named 'Factory
   default setting' that represents datastore with its preconfigured
   initial state.  This datastore resource is available using the
   following resource path:

This is backwards terminology wise. You introduce a new datastore and
then that datastore automatically maps to a RESTCONF resource, not the
other way round. You should not mix datastore definition and protocol
specifics like the RESTCONF resource path.

I am also not sure what exactly the factory-default datastore
contains. It sounds like simple static data but in reality many
devices do some probing of hardware to determine what the "factory
default" is, i.e., factory-default is not necessarily static.

Why do we need a capability identifier?

   i.e.,a new <factory> XML element is added to the input for
   the <copy- config> <get-config>,<get-data> operations.

I think this is wrong and not needed for get-data. And if NMDA is a
prerequisite for this, then we do not need to talk about get-config.

   For <copy-config> operation, the server MUST reset the target
   datastore to factory default setting according to the value of this
   element and return <ok> element in the NETCONF <rpc-reply> messages
   in success case.

If you include a RESTCONF example, make sure it is correct.

Appendix A of RFC 8342 provides guidelines how to define new
datastores. Should they not be followed?

The text says factory-default but the YANG module and the RESTCONF
example define / use <factory>.

I do not understand the reset operation (nor I am convinced yet that
copy-config is the right thing necessarily):

    rpc reset {
      nacm:default-deny-all;
      description
        "Request to reset the device to factory default setting
         and make configuration update to take effect.
         A server SHOULD send an rpc reply to the client before
         reset the device.";
    }

What is 'make configuration update to take effect.' How are the
various datastores modified if I invoke 'reset'? How do copy-config
and reset relate to each other? Why is reset nacm:default-deny-all
while copy-config etc. are not?

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