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

Andy Bierman <> Fri, 01 November 2019 22:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D208F120BC9 for <>; Fri, 1 Nov 2019 15:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i9bBDhYzX9Qf for <>; Fri, 1 Nov 2019 15:42:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8426012084A for <>; Fri, 1 Nov 2019 15:42:15 -0700 (PDT)
Received: by with SMTP id q28so8302142lfa.5 for <>; Fri, 01 Nov 2019 15:42:15 -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 :cc; bh=xdmL1RuyJXw2Ov4wwSk8tPT0eZU1ylws6/nlvkZLmps=; b=EEGyO8HUnDoVqYd9SBlQTrKr26cRZRAjTNHTbZEDH5XCEwGlAR2FN4kxLOqf/lMtB1 Fz7LeTXop/Ei4siJMhwrSjgEYPZjy53rP6HORdh3/qEHqtnCqpvTCaRlDnUlxLHAPn5g 1zXkDSXpULOQ5rCMSNEcQveEVdXW0UWwu7sLtLDbCkP2NAfZ4RRpNO3WB+10v4PDNb8u y1Iqm4wFRaRxsFRKMhczOPNdTMPQgn3RdNGb6vB272Ykeug4dwe5C4pfApET+ew4sFEl BTmTIdgop/ITb2X49Q0Pq4Lp3LU/eMXHrpJyCa9w5kzbsrHEqcx9pSjU648VJzBfZ5bp ixOg==
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:cc; bh=xdmL1RuyJXw2Ov4wwSk8tPT0eZU1ylws6/nlvkZLmps=; b=Je5hzpIZg2dBOLolryMTBlnn+//mYQQG8wM/cMrk7S19ekyq6F5xyrj4ja1TkTq2du 9KmmzYGwUsLDXSjTeR/U8wM0ZQnX+4S0C78VXiVzsLAc5ClYe11CNr8zU0yH5CQ96ZdU QBmG9Yox2HAiiTgWhL4O5WC/hULETwGVO0lw0c8ebeUFV9yv0VDrnxX4OXWPMjC19Ups 2gVngTveJH68c/iGgcIrPugcpCxexiq9HmjrTcQ8KzI66Kwhqmt/XupBmJYjJXGw8v6S MD4EyE1XeLSv4j65r+5+/ly6NOZ09IYSYEo/mCLtN9cYaAj98PWoeEqK0slu13PuMWWg steg==
X-Gm-Message-State: APjAAAWllTF8nTr257Qxs7nvhiH5qzohasl+G/+Qahyzwf2vPATKvs/A lqsameRz7cILSPi9zd0LyyN4xHOprXEDC16BCGAZ8b1j
X-Google-Smtp-Source: APXvYqy85AAsAVb1Uk4TvKeP7fkWyoGpcGZns5tq8q6/0boT/y9zcfwQVmyLu99GgNXLM0d/84Gb0xI4YOYNPK0VO9A=
X-Received: by 2002:ac2:511c:: with SMTP id q28mr8627429lfb.171.1572648133572; Fri, 01 Nov 2019 15:42:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Fri, 01 Nov 2019 15:42:02 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "" <>,
Content-Type: multipart/alternative; boundary="0000000000005bd3ef059650ad5f"
Archived-At: <>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.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, 01 Nov 2019 22:42:21 -0000


I have read draft-ietf-netmod-factory-default-05 and have the following

* sec 2. Specifying factory-reset content

This section uses SHALL (equivalent to MUST) to declare the implementation
details for
the server to load the factory-default content.  This is not appropriate
for a server implementation detail.
What hard to the Internet is caused if the server has some other way to
load the factory config?
This section should be removed.

point 1 is unclear what it means to derive the factory-config from the
current config.

point 2 specifies a file format but there is no way to specify the file.
What is the value added here?
Some servers can use an XML file (and will continue to do so, per point 3).

Why would this document specify that a dynamic datastore SHALL be empty
upon reset?
This is an implementation detail or a standard detail for some future work.

* Sec. 4: rpc factory-reset

This RPC has no NACM protections.
There should be a nacm:default-deny-all extension added to restrict access.
The client invoking the RPC MUST have permission to write all the existing
that is being replaced with factory-reset contents.

There is no mention of any operational disruption caused by setting the
config to factory-reset contents.
This will vary greatly depending on the implementation and current config.

What if the config includes session and client config?
This RPC can prevent any further management of the device.
That seems worth mentioning in the security considerations.

Overall the draft provides useful functionality so I support its

(BTW, my name is also misspelled in the draft)


On Fri, Nov 1, 2019 at 8:22 AM Kent Watsen <> wrote:

> This begins a two-week Working Group Last Call (WGLC) on
> draft-ietf-netmod-factory-default-05.  The WGLC ends on Nov 15 (two days
> before the NETMOD 106 session).  Please send your comments to the working
> group mailing list.
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.  Objections, concerns, and suggestions are also welcomed at
> this time.
> Thank you,
> NETMOD Chairs
> On Nov 1, 2019, at 1:59 AM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Network Modeling WG of the IETF.
>        Title           : Factory Default Setting
>        Authors         : Qin Wu
>                          Balazs Lengyel
>                          Ye Niu
> Filename        : draft-ietf-netmod-factory-default-05.txt
> Pages           : 11
> Date            : 2019-10-31
> Abstract:
>   This document defines a method to reset a server to its factory-
>   default content.  The reset operation may be used e.g. during initial
>   zero-touch configuration or when the existing configuration has major
>   errors, so re-starting the configuration process from scratch is the
>   best option.
>   A new factory-reset RPC is defined.  Several methods of documenting
>   the factory-default content are specified.
>   Optionally a new "factory-default" read-only datastore is defined,
>   that contains the data that will be copied over to the running
>   datastore at reset.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> netmod mailing list
> _______________________________________________
> netmod mailing list