Date: Mon, 20 May 2019 08:20:03 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Qin Wu <bill.wu@huawei.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20190520062003.i4wl2f7ekx34lctn@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Qin Wu <bill.wu@huawei.com>,
 "netmod@ietf.org" <netmod@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABAA4935F8C@nkgeml513-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA4935F8C@nkgeml513-mbx.china.huawei.com>
User-Agent: NeoMutt/20180716
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6-47easGa8zFpwP-IqvV-fUkufM>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-01.txt
Precedence: list

On Mon, May 20, 2019 at 05:57:02AM +0000, Qin Wu wrote:
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Juergen Schoenwaelder [mailto:j.schoenwael=
der@jacobs-university.de]=20
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B45=E6=9C=8817=E6=97=A5=
 19:15
> =E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>
> =E6=8A=84=E9=80=81: netmod@ietf.org
> =E4=B8=BB=E9=A2=98: Re: [netmod] I-D Action: draft-ietf-netmod-factory-=
default-01.txt
>=20
> I think this does not work:
>=20
>       [...]  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.
>=20
> You can't change the way things work. If something is committed to lets=
 say <running>, then this triggers the propagation to <intended> and even=
tually <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 th=
ree 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 propagate=
d 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.
=20
> Is it really useful to expose factory default to copy config? Or said d=
ifferenlty, 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 ass=
ign one single target datastore with factory default content, I am wonder=
ing 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.
>=20
> I am not sure this is true.
>=20
> For non-trivial devices, the default is likely not static but something=
 that takes into account device features available and the specific hardw=
are configuration present. It is actually somewhat unclear what the facto=
ry-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 a=
dd:
> "
> When its contents are considered sensitive, It is RECOMMENDED that the =
factory default=20
> Data is encrypted."

You propose to invent another layer of encryption???

/js

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>