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

Qin Wu <> Wed, 13 November 2019 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FB55120047; Tue, 12 Nov 2019 19:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2_FKJGCsMTdW; Tue, 12 Nov 2019 19:21:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A4E1D120019; Tue, 12 Nov 2019 19:21:50 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id E098E987625B1EE9C690; Wed, 13 Nov 2019 03:21:48 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 13 Nov 2019 03:21:48 +0000
Received: from ([]) by ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Wed, 13 Nov 2019 11:21:42 +0800
From: Qin Wu <>
To: "Rob Wilton (rwilton)" <>, Kent Watsen <>, "" <>, "" <>
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt
Thread-Index: AdWZ0MSRkpEiCPB8T0u5g3hLG8lN8A==
Date: Wed, 13 Nov 2019 03:21:42 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA94181FBdggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Nov 2019 03:21:54 -0000

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.

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


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


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


From: netmod <<>> On Behalf Of Kent Watsen
Sent: 01 November 2019 15:22
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,

On Nov 1, 2019, at 1:59 AM,<> 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

  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:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

netmod mailing list<>