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

Andy Bierman <> Fri, 17 May 2019 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B035812013E for <>; Fri, 17 May 2019 10:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iwvHR2fkyIwR for <>; Fri, 17 May 2019 10:37:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A73C91200F3 for <>; Fri, 17 May 2019 10:37:29 -0700 (PDT)
Received: by with SMTP id q17so5918929lfo.4 for <>; Fri, 17 May 2019 10:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vcY6be8PtnMngQ/MBRIX4SvxaARwJvNilYNLD3AVPA8=; b=twAwviN/L3aRDOgOvfOPvQF75I2F8KZ5YgQz/DHGbalbMNr3qCxwEZHk/4gOD0N/XE BhWJDogtfOWH+WmkJgVWzcMTYpCfeN/uJkhV6pCSQVlY2oW2bHA8XNg+pxfeH7y0nFS/ 7syXLZ7KOyLgv2m186a4pX2Wg8qnngfb4Q3DwePpUa47CPgjacytTGKYPZBYvB4R8mMg ybCJh0eIanO2l1ckN6IVAs4FfJep6gDTuzEH8lAVhdqdV3U/xiEEFFZK/Hgb4Z4LNVib tTIUA3LnkD6PMhq9Ih+O4XTm4pcN9qfsAdi8N+O4xPD8qbeUv+0pB/ZRk5mY6Y+2zOTx Zveg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vcY6be8PtnMngQ/MBRIX4SvxaARwJvNilYNLD3AVPA8=; b=WZF6pUvGJlY5y5gBV0kmlqVrylCDqPGWXxigfV7ecsdmk15e0EsBWJhmTHmQnb+/He OxzrCVsd5Po+O16Hbvr8ntapHZQ14tOlNTM37Hn/xZG0IyKXVH+PPFPqqUc/gOVR6FZT FuHk6YZpAcB3nHNDyNu17OFY75z+qCI2fL4z4hdyWmzoU0pFmOY/mTLh/RHLf7C99zx+ kRxv/k4+//JUu9jwlSTpwueAFmnV5C5uWU0aeDZgrDTOwRpm3H4Kd+hJkvgIezKwTLOx Lc87I/W2+MuyJJXMmRLz1eR9ELFX1UKges74qMeXJpKuAfqGt6g8GlH6fIk49ov9y0cn MUwQ==
X-Gm-Message-State: APjAAAWZf98T+OesAIQscWQvRyRjjhd4vlHsUGbS3Rz87e+BmXtBsyzj 70QSmUvqJ8KFHrQzF9DHtEdheCB51XJgPsLcsxFCwg==
X-Google-Smtp-Source: APXvYqzsxxuMYMFcA+FdA/Ipsh5sTcbaTmjBReTPD2DEuhe8usdUA8F/B+CUYWZsDwFY4PYexifeRqTVClD/pD9r4vc=
X-Received: by 2002:a19:6b04:: with SMTP id d4mr39648lfa.57.1558114647711; Fri, 17 May 2019 10:37:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 17 May 2019 10:37:16 -0700
Message-ID: <>
To: Juergen Schoenwaelder <>, Qin Wu <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000018c192058918d607"
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: Fri, 17 May 2019 17:37:33 -0000

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
should be standardized.

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

The copyright year needs adjustment. Indentation of the YANG
> statements should be fixed.
> /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