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

Qin Wu <> Mon, 20 May 2019 06:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72BD51200C4 for <>; Sun, 19 May 2019 23:27:49 -0700 (PDT)
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 ev3U4G1eEFYN for <>; Sun, 19 May 2019 23:27:47 -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 E6BF81200CC for <>; Sun, 19 May 2019 23:27:46 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id AFAF33DC737FA85FB8CE; Mon, 20 May 2019 07:27:44 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 20 May 2019 07:27:44 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 20 May 2019 07:27:44 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 20 May 2019 07:27:43 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Mon, 20 May 2019 14:27:36 +0800
From: Qin Wu <>
To: Andy Bierman <>, Juergen Schoenwaelder <>, "" <>
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
Thread-Index: AdUO1Fx01b7LzXPxS2GKTL6ITxiMkg==
Date: Mon, 20 May 2019 06:27:36 +0000
Message-ID: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA4938FC5nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.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: Mon, 20 May 2019 06:27:49 -0000

发件人: Andy Bierman []
发送时间: 2019年5月18日 1:37
收件人: Juergen Schoenwaelder <>; Qin Wu <>;
主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt

On Fri, May 17, 2019 at 4:15 AM Juergen Schoenwaelder <<>> wrote:
I think this does not work:

      [...]  For <copy-config> operation,it can be used to copy
      the factory default content to another datastore, however the
      content of the datastore is not propagated automatically to any
      other datastores.

You can't change the way things work. If something is committed to
lets say <running>, then this triggers the propagation to <intended>
and eventually <operational>. You can't come along and say that
copy-config from a particular source stops this.

Agreed. I have been objecting to the client-controlled datastore-specific factory reset.
I do not know of any devices which support such a thing.  I would like to
understand the use-cases that make this so useful and common practice that it
should be standardized.
[Qin]:There is misunderstanding on the last sentence of the quoted text. I will fix this.

Is it really useful to expose factory default to copy config? Or said
differenlty, would it not make sense to fix copy-config (at some other
place) so that it can generically work with new datastores?

   The content of the factory-default datastore is usually not security
   sensitive as it is the same on any device of a certain type.

I am not sure this is true.

For non-trivial devices, the default is likely not static but
something that takes into account device features available and the
specific hardware configuration present. It is actually somewhat
unclear what the factory-default datastore contains; the stuff I can
expect to see in <running> after the reset or some static stuff that
may be tweaked during the boot process to yield the initial <running>.
Or are we pretending these two are always the same?

The startup procedure within a server is very proprietary and can be
very different, even for vendors using the same server code.

There are no standard procedures today that allow a client to inject configuration
into this process. The client is allowed to alter configuration only after
the saved or factory configuration is loaded.  IMO it should stay this way.

e.g, : do not want to standardize:

   copy-config source=factory target=candidate
   edit-config target=candidate ...

This is the only use-case I can imagine for copy-config from factory,
but IMO it is not very important. (get-config(factory) + edit-config
already supports it.)

[Qin]:Not sure I understand the <startup> can not be intervened.
For writable running, we should allow copy-config operation copy the content to <running>
We should also allow copy config operation copy the content from <running> to <startup>
See the second figure in the following link:

The copyright year needs adjustment. Indentation of the YANG
statements should be fixed.



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