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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 11 November 2019 11:58 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA761200FA; Mon, 11 Nov 2019 03:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=amBZ3g9d; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xuRo2NTI
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SRmhHTwJ9OP; Mon, 11 Nov 2019 03:58:31 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EC21200DB; Mon, 11 Nov 2019 03:58:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44462; q=dns/txt; s=iport; t=1573473511; x=1574683111; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JPLbZMRaLIQxmFX71wddYXBcrOY5xRGEZ284QxAhLRA=; b=amBZ3g9dGvfDVQ+rnbmH0uuTt+NgnL7PJGIlFlj2RC/hqAdhXca6Moe8 S+LvfFrxvioZYbKPpHJPXZQYdljSMdeHBB2x0RPW5Ob7injvC5Ni3Nj2k BkXpALY2rdCBrcMfmTFAU8L0ftn8k/u8aY/IBTB3N3/xyPsjJPC3u4KT3 c=;
IronPort-PHdr: =?us-ascii?q?9a23=3AnrgwNRVS8/g+TKpKWbLzFInnM+/V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgA8VGSFhj13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvEADoS8ld/5ldJa1cCRwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF+gRwvUAVsWCAECyoKh2UDimlOghCYAIFCgRADVAkBAQEMAQE?= =?us-ascii?q?YAQwIAgEBg3tFAoQUJDgTAgMLAQEEAQEBAgEFBG2FNwyFUQEBAQEDAQEQGxM?= =?us-ascii?q?BASwMDwIBCBEEAQEhAQYHJwsUCQgCBAESCBqDAYF5TQMuAQIMoFwCgTiIYII?= =?us-ascii?q?ngn4BAQWBOAIOQYJ5GIIXCYE2jBQYgUA/gRFGgU5+PoJiAQECAQEWgR0TAQI?= =?us-ascii?q?WKwmDDIIslU8kmCEKgiWHF45Igj1yhm8FhDCLJo5HiDaRQAIEAgQFAg4BAQW?= =?us-ascii?q?BaSIqgS5wFRohgmwJRxEUgWmOTYNzhRSFP3SBKIsqgTABgQ4BAQ?=
X-IronPort-AV: E=Sophos;i="5.68,292,1569283200"; d="scan'208,217";a="665993379"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2019 11:58:29 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id xABBwTl4021089 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2019 11:58:30 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 05:58:29 -0600
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 06:58:27 -0500
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 11 Nov 2019 05:58:27 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B7vphPaUB+e5yvsYkLPPUDMi7x4lteYnrESUZDCLrcne2QEM/AZqhquglgYOS1CwMaMEYPuTIfGQ6VORUwbIutejB9ZU0r0/RxBn/0QokHm715CxFjNVYwc7/0x3vYPX5XBnRFMb0okAqQpH9zb9WrOYKKNpDrCtIVbdk7Zmzfc2rXqluH7I3+04af/wmGjGsYxAfEURm524DO+j08mq+8mFnsF+5zE2BlnjVM5L1JgQzbEUucekQu9DGbsWJxEncVRw1v4835kN+6GKdICfI5Ef4N3D448Rt5jXK0W+lIsy7IDEXHWXexLJPpizMfVRlvwhO4kG31iYXlWRwPee1g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ibBZPF9V8MsRDB9JltNUL8as4ZJw2Yoeqr/cwDhiYYQ=; b=ZZZ92fxyKOVTK524I8hd+J6aUsb5lb9zEdscLc0I4fnTAhcGABb29gqLRuoAzO08ONL9mLjW0+IOosOaor1/YAHLF2Ro6xAVvPvpZ7IQWsr1zetkqwWk6qsZKm0VtEqFj9T0FciAD9D0fk4TTSPlrU2Kdpio2X9M19oOun3nRFfWl5W9H/1jSdfp0OftBTB7iZspJavWMdq4qCdfIMDwj4yGaehgKuX93Dmo7nazcYlJeKT8UShw/3kXyDmljKeZH9kx9Ey41BT5QbjMroC8cE//mekvnw1qAQyL+LJDqFAAb2eLwEXskSe/56mL+xX5Q6Jvu+rfPvavTawCFbijwg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ibBZPF9V8MsRDB9JltNUL8as4ZJw2Yoeqr/cwDhiYYQ=; b=xuRo2NTI0y3/0bU3tRz+eD2WsVzMol0qFJ5Cd9jjkpXq2NCViQ9mTcj4zoLdsiLQNNA9sz+qPvS3TGtzrU18qEGYGQuncdotxl0Q8rPXm5+UnJqxZ8hnDMmUkutBbEyUz7FP2k/k7E65c5q/lLiBf+z2C1rMILGcyztfOCPfl/c=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3599.namprd11.prod.outlook.com (20.178.251.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Mon, 11 Nov 2019 11:58:26 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::49b6:bc5c:bd3e:203c%5]) with mapi id 15.20.2430.027; Mon, 11 Nov 2019 11:58:26 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-factory-default@ietf.org" <draft-ietf-netmod-factory-default@ietf.org>
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt
Thread-Index: AQHVkHmyh9DcrmYBakOAQzvzduoHL6d2bz4AgA9c7KA=
Date: Mon, 11 Nov 2019 11:58:25 +0000
Message-ID: <MN2PR11MB4366E382DB1B3D823215416AB5740@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <157258797979.30380.14870732293250173185@ietfa.amsl.com> <0100016e278f0bb9-897e5aa9-0a49-4bf9-ae2d-9b3372a38695-000000@email.amazonses.com>
In-Reply-To: <0100016e278f0bb9-897e5aa9-0a49-4bf9-ae2d-9b3372a38695-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.60]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 09454ff0-5fe2-4b7a-b9ef-08d7669e75c2
x-ms-traffictypediagnostic: MN2PR11MB3599:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <MN2PR11MB359951A6686BCE58C5C55035B5740@MN2PR11MB3599.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0218A015FA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(376002)(366004)(346002)(51444003)(199004)(189003)(316002)(186003)(110136005)(26005)(86362001)(5660300002)(2501003)(52536014)(486006)(4001150100001)(14444005)(446003)(11346002)(256004)(71190400001)(476003)(71200400001)(966005)(478600001)(14454004)(25786009)(55016002)(6306002)(54896002)(9686003)(236005)(6436002)(6116002)(229853002)(76116006)(66946007)(6246003)(606006)(9326002)(8936002)(81166006)(81156014)(8676002)(53546011)(6506007)(76176011)(66476007)(790700001)(7696005)(66574012)(102836004)(66556008)(99286004)(7736002)(74316002)(66066001)(33656002)(2906002)(3846002)(66446008)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3599; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HU6yaZk0df106tUchhHB3rxAvkZTccNtYOm5YgDNVN/5ZuwTpKVDGIKbL1e6nuoq5ETD38LRAcI75cWULh8eAl9zfSqzMXWgn1i9+aGcUaGCBFuUHnKYis4IWoDbgBAT6xfHpn79bgLQkzMibWMbZRpAy+iUbw9bH2ZCT7yhcMWB/DiZVshGdD8SgqlKFIZfydFahPgwO2660OAsqxVDPVoUcMPFKSb6R08BNUix0jS1EMhGHqmV5YFvzCxFzNguaxm5o62jgTFn+4gCQP8PUOgi4SjgmA7Prr4qk33S8qnHbdx6CwAFJgYC+ZtZWbvE01s7Xw2eWwp9Os1iWmgIS98tF/aI/ehwBZ9d9HVmi8eRqc37WzLCItgCrCLtWlP3bAN77VEGKRh8kaDMmYdNAlpKG9Nht1XfNVU+wWf69ImhRqRNO2QQf4CL2NDTOovMoiO+0ypMZsiwIxnYrzdVTSQRSfbY95HIDmE+3kHFHyc=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366E382DB1B3D823215416AB5740MN2PR11MB4366namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 09454ff0-5fe2-4b7a-b9ef-08d7669e75c2
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2019 11:58:25.9967 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0H/pEa9fyBahqO0gklfx1ZLkr9mokb1uleXeuzCsMRGH1MXzwDP28CbOxIh+jpIO+qNK42na4mOwxSvFQyxtSg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3599
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jc5NSJZ1P2NaE6I9BjVroHvEYTo>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 11:58:34 -0000

Hi,

I've reviewed draft -06 and have the following LC comments.

Section 1, in Introduction (probably the abstract could be similarly tweaked):


  1.  Suggest changing "... major errors, so re-starting ..." to "... major errors and so restarting ...".  This could also be fixed in the abstract.


  1.  Suggest deleting the sentence "When resetting a datastore all previous configuration settings will be lost and replaced by the
   factory-default content".  I think that this can covered further in the document, and doesn't need to be stated in the introduction.


  1.  Suggest changing "A new factory-reset RPC" to "A factory-reset RPC"


  1.  Regarding "Optionally a new "factory-default" read-only datastore is defined, that contains the data that will be copied over to all read-write configuration datastores at reset".



I suggest changing "read-write configuration datastores" to "read-write conventional configuration datastores", and import "conventional configuration datastore" from RFC 8342.  Also, I think that section 3 should be updated to indicate that the datastore is OPTIONAL to implement.  Hence proposed replacement text:



"A "factory-default" read-only datastore is defined, that contains the data to replace the contents of implemented read-write conventional configuration datastores when reset."


  1.  I'm not sure that the paragraph about the <delete> operation (presumably this should be <delete-config>) is required at all.  If you do want to retain it, then I would suggest condensing it from:

"   NETCONF defines the <delete> operation that allows resetting the
  <startup> datastore and the <discard-changes> operation that copies
   the content of the <running> datastore into the <candidate>
   datastore.  However it is not possible to reset the running
   datastore, to reset the candidate datastore without changing the
   running datastore or to reset any dynamic datastore.

   A RESTCONF server MAY implement the above NETCONF operations, but
   that would still not allow it to reset the running configuration."

to

"NETCONF defines the <delete-config> RPC operation,  but that only acts on the <startup-datastore>, whereas the <factory-reset> RPC operation can perform additional changes to the device to fully reset the device back to a factory-default state."


Section 1.1, Terminology,

  1.    "candiate => candidate".


  1.  "factory-default datastore", I think that this should be defined as a "A read-only configuration datastore ..."

Section 2. Factory-Reset RPC:

  1.  I think that this could be more prescriptive about how the datastores are reset:
     *   All supported conventional read-write configuration datastores (i.e. <running>, <startup>, and <candidate>) are all reset to the contents of <factory-default>,
     *   Read-only datastores receive their content from other datastores, e.g., <intended> is updated due to the config changes to <running>,
     *   All data in any ephemeral datastores MUST be discarded,
     *   The contents of the <operational> datastore MUST be reset back to an appropriate factory-default state,.


  1.  I agree with Andy about deleting the text on how the factory-default contents is defined.

Section 3, Factory-Default Datastore
  "Management operations":

  1.  Should indicate that the datastore is OPTIONAL to implement.  A device MAY only implement the <factory-reset> RPC without implementing the datastore, thus loosing the ability to see what configuration the device would be reset back to.



  1.  It is unclear what a "specialized, dedicated operation" is.  Does this mean an NETCONF/RESTCONF RPC, or something outside of YANG management protocols altogether?  Perhaps change this to "dedicated RPC operation"


  1.  Suggest changing "The contents of the datastore can be read using NETCONF <get-data> and <get-config> operations, and the RESTCONF protocol equivalents. to "The datastore can be read using the standard NETCONF/RESTCONF protocol operations."



  1.  Suggest changing "The operation <factory- reset>" to "The <factory-reset> RPC operation".  Perhaps also import the "RPC operation" definition from RFC 7950?


  1.  " On devices that support non-volatile storage, the contents of <factory > MUST persist across restarts."



The factory-default datastore is only useful if persists across restarts, so I would change this statement to: "The contents of <factory-default> MUST persist across device restarts."

Section 4: YANG Module

  1.  Please add references to the import statements.
  2.  Remove reference to <get-config> in the description, and realign the description text.
  3.  Change feature name from "factory-default-as-datastore" to "factory-default-datastore"
  4.  Please expand on the description associated with the "factory-reset" RPC since it can be impact other datastores and file contents, or reference back to the appropriate section of the RPC.
  5.  Change description of "factory-default" identity to "This read-only datastore contains the configuration data used to replace the contents ofthe read-write conventional configuration datastores during a factory-reset RPC operation."

Appendix A:

  1.  I wasn't sure that this section is required at all.

Thanks,
Rob


From: netmod <netmod-bounces@ietf.org>; On Behalf Of Kent Watsen
Sent: 01 November 2019 15:22
To: netmod@ietf.org
Cc: draft-ietf-netmod-factory-default@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-factory-default-05.txt



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, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> 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:
https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-factory-default-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-factory-default-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod