Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

"Rob Wilton (rwilton)" <> Tue, 26 March 2019 07:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93D3612028B for <>; Tue, 26 Mar 2019 00:01:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lKU8YgT4gT65 for <>; Tue, 26 Mar 2019 00:01:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20D59120284 for <>; Tue, 26 Mar 2019 00:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14326; q=dns/txt; s=iport; t=1553583716; x=1554793316; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aYts3QEkQ7pHOp9SgzFi6xPeAa9NvAG/arVatJ3ayOQ=; b=RIgoXQD30/u/1zIc0k9FuXrvqPqVd4F0dfhUVEJYxyGKtvNpv4IAkPds Nl26IFH1VUbU7gyebLX9O7wsHnNBnc4Rz/YE8FaGpjbQettz9jA0F7hov hbeDo3GgSKMxJfm2Bee/n9fE6/AJuKlldkTyIhdVeNe3rhtDTiUFlrTCw Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208,217";a="539625388"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 07:01:54 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x2Q71smE012373 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 07:01:54 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 02:01:53 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 02:01:53 -0500
From: "Rob Wilton (rwilton)" <>
To: Kent Watsen <>, "" <>, =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <>, Qin Wu <>
Thread-Topic: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
Thread-Index: AQHU40pAE0rZobHHcEaspplVrDxwYKYdd2DA
Date: Tue, 26 Mar 2019 07:01:53 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7cc1a662c56748eb8edfc767735d4a5dXCHRCD007ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
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: Tue, 26 Mar 2019 07:01:59 -0000

I support this draft as a starting place for this work, but I would like to see some changes in the final solution:

I think that having a datastore report the factory default configuration is good, and it is also right that this should be optional to implement, since some devices might not have default factory configuration, but instead run a first boot sequence to construct an initial configuration.

I don’t really understand the need to be able to perform a factory reset on a per datastore basis, but instead I would prefer to see a single device level factory reset RPC.  Such an RPC may do more than just resetting the configuration and rebooting the device, it might also change the software version, wipe areas of storage such as log files, cached files, etc.  Possibly, some of these options could be controlled via parameters to the RPC if there is enough commonality, of otherwise vendors could augment in their own options to a minimal standard RPC.

Copying from <factory-default> to another datastore is OK with me, although I don’t see any particular need/value in doing this, hence I would rather see <copy-config> fixed more generically to allow copying between two configuration datastores than specifically augmenting specifically for this datastore.  Hence, I think that extending/replacing the <copy-config> RPC could probably be deferred to a NETCONF-bis or NETCONF-NMDA-bis document.

I don’t see a need for this document to reference or refer to the instances-data draft.  I think that using instance-data rather than a factory-default datastore is just an internal implementation detail and shouldn’t be exposed to the user.

However, Balazs, I do see merit in allowing the contents of any configuration datastore to be loaded from an instance-data file, or written to an instance data file (either local or remote).   But, I don’t think that this should go into this draft, and probably it is too late to add this to the instance-data draft.


From: netmod <> On Behalf Of Kent Watsen
Sent: 25 March 2019 21:35
Subject: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

This email begins a 2-week adoption poll for:

Please voice your support or objections before April 8.<x-apple-data-detectors://1>

Kent (and Lou)