Re: [netmod] Question on draft-wu-netmod-factory-default

Qin Wu <> Tue, 26 March 2019 05:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5E7312027D for <>; Mon, 25 Mar 2019 22:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F-rQyYrmT9ES for <>; Mon, 25 Mar 2019 22:15:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CC4712027B for <>; Mon, 25 Mar 2019 22:15:45 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id B63C7A2A81B613825A65; Tue, 26 Mar 2019 05:15:43 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 26 Mar 2019 05:15:43 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Tue, 26 Mar 2019 13:15:40 +0800
From: Qin Wu <>
To: Juergen Schoenwaelder <>, Joe Clarke <>
CC: "" <>
Thread-Topic: [netmod] Question on draft-wu-netmod-factory-default
Thread-Index: AdTjkPCwnvydF2AuQoOdsCxKRcPpiw==
Date: Tue, 26 Mar 2019 05:15:40 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] Question on draft-wu-netmod-factory-default
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 05:15:48 -0000


发件人: netmod [] 代表 Juergen Schoenwaelder
发送时间: 2019年3月25日 23:31
收件人: Joe Clarke <>
主题: Re: [netmod] Question on draft-wu-netmod-factory-default

The I-D says:

   o  factory-default datastore: A read-only datastore holding a
      preconfigured minimal initial configuration that can be used to
      initialize the configuration of a server.  The content of the
      datastore is usually static, but MAY depend on external factors
      like available HW.

The problem here is the phrase 'can be used to initialize the configuration of a server'. In terms of the well-known NMDA datastores, it is not clear whether the content is copied to <running> or <startup> or both. Section 2 adds a bit more confusion since it

   Factory-default content SHALL be specified by one of the following
   means in order of precedence

   1.  For the <running>, <candidate> and <startup> datastores as the
       content of the <factory-default> datastore, if it exists

So do all these configuration datastores receive a 1:1 copy of <factory-default>?
[Qin]: This is close to what Andy is asking, we allow multiple target datastore to be reset.
 If so, if we have a <factory-default>, why is invoking <copy-config> not good enough?
[Qin]: Netconf <copy-config> operation needs to be extended to allow it to operate on the factory-default datastore.
   2.  YANG Instance Data [I-D.ietf-netmod-yang-instance-file-format]

How would this be done? I do not see anything in reset-datastores that provides instance data. The copy-config operation already allows to provide source config inline. Why do we need another way of doing the same?
[Qin]: In normal copy-config operation, how do we source config inline is used for factory default setting.
 YANG instance data draft could provide generic solution for this. We add a note to see if there is additional parameters that need to be added, will see how to address this.

I do not really understand why one would need to have reset-datastore on <candidate> - is <discard-changes> not good enough?
[Qin]: It doesn't allow you reset to <candidate> without changing <running>.
Please fix the 'target-datasore' typo or better change the parameter name to just 'datastore'.
[Qin]: Okay,will figure out the right terminology.
Should there be text explaining how an implementation is supposed to deal with errors or will these resets never fail?
[Qin]: Okay, will add text in the next version.

On Mon, Mar 25, 2019 at 10:14:03AM -0400, Joe Clarke wrote:
> I support the need for being able to reset a DS to its factory default.
> However, I have a question on the current design of the model and the 
> "factory-default" DS.
> It seems to me that this is a single DS that might have been intended 
> to reset running or startup.  However, what if I have different DSes 
> that each have unique factory default data?  If I choose to extend 
> factory-default with a new identity of my other DS, how can I indicate 
> that the target DS will be reset to _that_ DS?  Does that make sense?
> Or if I do a <get-data> on a factory-default DS, how do I know what 
> other DSes does this DS pertain?  Perhaps the server will use this to 
> reset a given DS, but how would a user know that (other than perhaps 
> naming of the factory-default DS)?
> Maybe the module needs a mapping to let the client know what DS will 
> be used to reset what other DS?
> Joe
> _______________________________________________
> netmod mailing list

Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>

netmod mailing list