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

[Qin Wu <[e-mail]>]

Thanks Rob, the proposed changes and polishing make sense to me. Thanks.
Regarding the question on 11, I think it is unlikely we should change the content of read only datastore, currently there are no standard way to do this.
But it doesn’t prevent dedicated operation is defined in the future or proprietary partial solution already. Hope this clarifies.

-Qin
发件人: Rob Wilton (rwilton) [mailto:[e-mail]]
发送时间: 2019年11月11日 19:58
收件人: Kent Watsen <[e-mail]>; [e-mail]; [e-mail]
主题: RE: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt

Hi,

I’ve reviewed draft -06 and have the following LC comments.

Section 1, in Introduction (probably the abstract could be similarly tweaked):


  1.  Suggest changing “… major errors, so re-starting …” to “… major errors and so restarting …”.  This could also be fixed in the abstract.


  1.  Suggest deleting the sentence “When resetting a datastore all previous configuration settings will be lost and replaced by the
   factory-default content”.  I think that this can covered further in the document, and doesn’t need to be stated in the introduction.


  1.  Suggest changing “A new factory-reset RPC” to “A factory-reset RPC”


  1.  Regarding “Optionally a new "factory-default" read-only datastore is defined, that contains the data that will be copied over to all read-write configuration datastores at reset”.



I suggest changing “read-write configuration datastores” to “read-write conventional configuration datastores”, and import “conventional configuration datastore” from RFC 8342.  Also, I think that section 3 should be updated to indicate that the datastore is OPTIONAL to implement.  Hence proposed replacement text:



“A "factory-default" read-only datastore is defined, that contains the data to replace the contents of implemented read-write conventional configuration datastores when reset.”


  1.  I’m not sure that the paragraph about the <delete> operation (presumably this should be <delete-config>) is required at all.  If you do want to retain it, then I would suggest condensing it from:

“   NETCONF defines the <delete> operation that allows resetting the
  <startup> datastore and the <discard-changes> operation that copies
   the content of the <running> datastore into the <candidate>
   datastore.  However it is not possible to reset the running
   datastore, to reset the candidate datastore without changing the
   running datastore or to reset any dynamic datastore.

   A RESTCONF server MAY implement the above NETCONF operations, but
   that would still not allow it to reset the running configuration.”

to

“NETCONF defines the <delete-config> RPC operation,  but that only acts on the <startup-datastore>, whereas the <factory-reset> RPC operation can perform additional changes to the device to fully reset the device back to a factory-default state.”


Section 1.1, Terminology,

  1.    “candiate => candidate”.


  1.  “factory-default datastore”, I think that this should be defined as a “A read-only configuration datastore …”

Section 2. Factory-Reset RPC:

  1.  I think that this could be more prescriptive about how the datastores are reset:
     *   All supported conventional read-write configuration datastores (i.e. <running>, <startup>, and <candidate>) are all reset to the contents of <factory-default>,
     *   Read-only datastores receive their content from other datastores, e.g., <intended> is updated due to the config changes to <running>,
     *   All data in any ephemeral datastores MUST be discarded,
     *   The contents of the <operational> datastore MUST be reset back to an appropriate factory-default state,.


  1.  I agree with Andy about deleting the text on how the factory-default contents is defined.

Section 3, Factory-Default Datastore
  “Management operations”:

  1.  Should indicate that the datastore is OPTIONAL to implement.  A device MAY only implement the <factory-reset> RPC without implementing the datastore, thus loosing the ability to see what configuration the device would be reset back to.



  1.  It is unclear what a “specialized, dedicated operation” is.  Does this mean an NETCONF/RESTCONF RPC, or something outside of YANG management protocols altogether?  Perhaps change this to “dedicated RPC operation”


  1.  Suggest changing “The contents of the datastore can be read using NETCONF <get-data> and <get-config> operations, and the RESTCONF protocol equivalents. to “The datastore can be read using the standard NETCONF/RESTCONF protocol operations.”



  1.  Suggest changing “The operation <factory- reset>” to “The <factory-reset> RPC operation”.  Perhaps also import the “RPC operation” definition from RFC 7950?


  1.  “ On devices that support non-volatile storage, the contents of <factory > MUST persist across restarts.”



The factory-default datastore is only useful if persists across restarts, so I would change this statement to: “The contents of <factory-default> MUST persist across device restarts.”

Section 4: YANG Module

  1.  Please add references to the import statements.
  2.  Remove reference to <get-config> in the description, and realign the description text.
  3.  Change feature name from “factory-default-as-datastore” to “factory-default-datastore”
  4.  Please expand on the description associated with the “factory-reset” RPC since it can be impact other datastores and file contents, or reference back to the appropriate section of the RPC.
  5.  Change description of “factory-default” identity to “This read-only datastore contains the configuration data used to replace the contents ofthe read-write conventional configuration datastores during a factory-reset RPC operation.”

Appendix A:

  1.  I wasn’t sure that this section is required at all.

Thanks,
Rob


From: netmod <[e-mail]<mailto:[e-mail]>> On Behalf Of Kent Watsen
Sent: 01 November 2019 15:22
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt


This begins a two-week Working Group Last Call (WGLC) on draft-ietf-netmod-factory-default-05.  The WGLC ends on Nov 15 (two days before the NETMOD 106 session).  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
NETMOD Chairs



On Nov 1, 2019, at 1:59 AM, [e-mail]<mailto:[e-mail]> wrote:


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-05.txt
             Pages           : 11
             Date            : 2019-10-31

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-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-05

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


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/

_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod