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

Kent Watsen <> Mon, 20 May 2019 13:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4144412017E for <>; Mon, 20 May 2019 06:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] 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 hsGzuKAIYPt1 for <>; Mon, 20 May 2019 06:57:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D549612012C for <>; Mon, 20 May 2019 06:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw;; t=1558360648; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6PqxepbhTubTn1SK2jGBdjdTtbgwtmnMlsuiuLxn3HM=; b=esIJMHzSEl1TFh73jFG6dWg8L/u5NvoM18wfBLeqxp1JGvDkm7BLPhE4ptXPsPfJ euHdiPPexFZdOu27A4vQnBCAsq5MRP7tTqArQd/t3uYUJVEHwkV85enQHvhJ7pHPZOq AVfMFwbkOyhbjlg7kXVQLmLlDSNBEtWBdki8pZyg=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_275793E0-75A3-4814-9085-E878E05A49D0"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 20 May 2019 13:57:28 +0000
In-Reply-To: <>
Cc: "Rob Wilton (rwilton)" <>, "" <>
To: Juergen Schoenwaelder <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.20-
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 13:57:32 -0000

The <copy-config> value-proposition is limited and not worth special effort to make happen.
  - RFC 6241: augment statements are needed to add to the existing RPCs, so just support
  - RFC 8040: datastore aren't supported,  there's no way to access the "factory-default" datastore.
  - RFC 8342: Appendix A needs to be observed, which this draft does in its Section 3 (note, a
                       reference to Appendix A should be added here).
  - RFC 8526's <get-data> and <edit-data> come along for free (though edits would fail due to this
          new datastore being read-only.  Note that RFC 8526 does not define a <copy-data> RFC...
  - RFC 8527's datastore resource (i.e., /ds/ietf-datastores:operational:factory-default) and all the
          standard HTTP operations (OPTIONS, HEAD, GET, etc.)  come for free but, again, there is
          no "COPY" operation

Just supporting <get-config> (and not <copy-config>) is the most consistent option.

PS: the "WG Chair" lines should be removed from he YANG module.  We don't do that anymore.

Kent // contributor

> On May 20, 2019, at 6:31 AM, Juergen Schoenwaelder <> wrote:
> +1
> /js
> On Mon, May 20, 2019 at 09:53:35AM +0000, Rob Wilton (rwilton) wrote:
>> If the purpose of the extending the copy-config operation to the factory-default datastore is just another generic way to do the factory-reset RPC then I would suggest that we don't modify copy-config as part of this draft.  Instead, I think that it would be good to fix this generically (for any datastore) in a future update of NETCONF - I see that you have already raised to track this.
>> In theory, a client could use copy-config in a slightly different way to the factory-reset RPC, i.e., to copy from the factory-default to candidate, then have the client modify the configuration until they are happy with it, before committing it.  But I'm not sure that this in the best approach.  If I was writing a client, I would choose to code the client to read from the factory-default datastore (if needed), then construct whatever the desired configuration of the device is, before pushing it to device.
>> For me, I think that the most important parts of this draft are being able to read from the factory-default datastore, and having an RPC to reset the device back to the factory-default state.  I would probably defer updating copy-config until it can be fixed properly in NETCONF.
>> Thanks,
>> Rob
>>> -----Original Message-----
>>> From: netmod <> On Behalf Of Juergen Schoenwaelder
>>> Sent: 20 May 2019 07:20
>>> To: Qin Wu <>
>>> Cc:
>>> Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
>>> On Mon, May 20, 2019 at 05:57:02AM +0000, Qin Wu wrote:
>>>> -----邮件原件-----
>>>> 发件人: Juergen Schoenwaelder
>>>> []
>>>> 发送时间: 2019年5月17日 19:15
>>>> 收件人: Qin Wu <>
>>>> 抄送:
>>>> 主题: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
>>>> 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.
>>>> [Qin]:Automatic propagation we were referred to is that when we have
>>>> three datastores, let's say datastore A, datastore B, datastore C, one
>>> time <copy-config> operation can not copy content of datastore A to
>>> datstore B and datastore C at the same time, But you are right, content of
>>> <running> will be automatically propagated to <intended> and <operational>,
>>> we will see how to tweak the text.
>>> This is not what the text says. And given the parameters of copy-config, it
>>> is obvious that you can't copy to multiple datastores.
>>>> 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?
>>>> [Qin]: Note that this is just an option feature to <copy-config> to
>>> assign one single target datastore with factory default content, I am
>>> wondering why it can not be defined in this draft in a more generic way?
>>>> Even in RFC6241bis or a separate draft, if you add this feature support
>>> to <copy-config>, you will augment <copy-config> in the same way, if my
>>> understanding is correct.
>>> No. You would allow any datastore, not a specific one.
>>>>   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?
>>>> [Qin]: We emphasize "usually not", to address your comments, we could
>>> add:
>>>> "
>>>> When its contents are considered sensitive, It is RECOMMENDED that the
>>>> factory default Data is encrypted."
>>> You propose to invent another layer of encryption???
>>> /js
>>> --
>>> 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
> -- 
> 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