Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04

Kent Watsen <kwatsen@juniper.net> Mon, 11 September 2017 17:12 UTC

Return-Path: <kwatsen@juniper.net>
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 CB90F132D97 for <netmod@ietfa.amsl.com>; Mon, 11 Sep 2017 10:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level:
X-Spam-Status: No, score=-4.799 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 mcVLkE8b7B1S for <netmod@ietfa.amsl.com>; Mon, 11 Sep 2017 10:12:46 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B70B13316A for <netmod@ietf.org>; Mon, 11 Sep 2017 10:12:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AnoorilZOTVv7A3VxOvJzDnyr27K5MhisQQO/y3LORI=; b=b9iXx0E0slFTTaP1Y/4RQETjdfH8QS+Dq6YAe0rR0rQhqry6PtnsXiQWIaCCMrbHhY+1LnG047VuR4IzOakgUzCySJGR2Fcz9ijdUJi7/y+iQgPOstD0VnAYCKUhWGnRRBV/f//H/ZUbUJxyKHqi3zsUY8MIg22V2vVdrLzB5uQ=
Received: from BLUPR05MB275.namprd05.prod.outlook.com (10.141.22.149) by BLUPR05MB644.namprd05.prod.outlook.com (10.141.205.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Mon, 11 Sep 2017 17:12:43 +0000
Received: from BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) by BLUPR05MB275.namprd05.prod.outlook.com ([10.141.22.149]) with mapi id 15.20.0035.010; Mon, 11 Sep 2017 17:12:43 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: Robert Wilton <rwilton@cisco.com>, Lou Berger <lberger@labn.net>, "netmod WG" <netmod@ietf.org>
Thread-Topic: WG Last Call: draft-ietf-netmod-revised-datastores-04
Thread-Index: AQHTI2WiK2FD9vRWGUCWyOwPy47k86Kv3KKA///b3oA=
Date: Mon, 11 Sep 2017 17:12:42 +0000
Message-ID: <E1A72908-D7D6-4FDF-BF77-8E6B0D2CFB4B@juniper.net>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
In-Reply-To: <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR05MB644; 6:tbG2u3hbdd1HzHJ2BJUAAJWtRZ5/9cdQ4km5sbc4bDy7h/NwuC3reKozqloEVVF9Wuwnen7uLrXiINS3fp+aY11d7YTnAiEDqfCmawmkT43Qr/HO2Ri1c5rQ/W3BXp78gD+vQIORwhMLar8r8BWmqZ3pal8Blx6XlnKJl4+ddESL5V5aVo8xf9wwmDCj+dOs2Pk6pVhs0ruRryve7KL1/OK96j2a/TUIBb0q8BfshZLhPYGmZAeZ0Qdx7GVN/zGwZn//NI5IQlKF0AmluosKhzBCAHuPcSeTRiQI8/m8oiDPscgVYbWAMykwj6ZnSBAjJTh8KYqZV/+7EqffjTav+g==; 5:8Q66i3r31d7BG7q8YQFq0wC4auvGimlZBXDwK+5HVD6dLIq8v36YtfTs7i1wskaPLB9BxUtMu0U7xr+K7bwPKNm8qPqIt3yeHx+CR8684c1PMkiPI+UdZ8mIctTwiHhdJO/LcDIyIB2pOBfVxx3QRw==; 24:ZBW4U2n+msYxCam0H/MhJKKlwqIJHJDGNUeNjD72UnEZCj5Ko6Wf0D1WOp7TwN8FnAtjawrfyjuRWVlZSMwfn2soRoKURIxOkyehxADE7Cg=; 7:OuEs1/shzxwTWL2YxSrwfzpaO/wYrgJecpm+VhdOtGdwvXwOvrERdo4ju6MfE6ZJe9UuF0o8ui2Z0J87svnDHguNcLn2jqAPLj0E1HGx4ctL5AYRw257PmOHyvS2Ty7GVa1sZpptpZmJAAiYFndN0+5XaRwEAWTNgLEkn22ebsLbj8eOurAbTKO0nnWCn8epL3jS5R+Hh4/AE8nP5MsOFVEwsUS30tmW5rGh8gbzGgA=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3b9d030f-22e9-404c-0956-08d4f938508b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR05MB644;
x-ms-traffictypediagnostic: BLUPR05MB644:
x-exchange-antispam-report-test: UriScan:(95692535739014)(21748063052155);
x-microsoft-antispam-prvs: <BLUPR05MB64496097CEAEDF9410155BBA5680@BLUPR05MB644.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR05MB644; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR05MB644;
x-forefront-prvs: 04270EF89C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(199003)(377454003)(15374003)(24454002)(189002)(51444003)(105586002)(230783001)(6436002)(3660700001)(83506001)(6506006)(53936002)(86362001)(478600001)(8676002)(3280700002)(14454004)(6486002)(2906002)(83716003)(229853002)(53546010)(66066001)(6116002)(36756003)(102836003)(236005)(7736002)(2900100001)(5660300001)(8936002)(81156014)(82746002)(76176999)(4001350100001)(3846002)(68736007)(25786009)(106356001)(81166006)(2950100002)(33656002)(50986999)(54356999)(6246003)(99286003)(77096006)(189998001)(54896002)(101416001)(6306002)(6512007)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB644; H:BLUPR05MB275.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_E1A72908D7D64FDFBF778E6B0D2CFB4Bjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2017 17:12:43.0075 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB644
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MdrN6L9ArZAprAGZfbdd1igc24g>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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 Sep 2017 17:12:49 -0000

As an author, I believe the draft is ready for publication.

Regarding Robert's editorial suggestions:

1) how moving "all" like this?  (i.e., must have same modules, deviations, etc.)
-   datastores that all share exactly the same schema, allowing data to be copied
+  datastores that share exactly the same schema, allowing all data to be copied

2) better, but I think we should expand "It" in the beginning of the 2nd paragraph
to "The intended configuration datastore".  Also, how about this for the 3rd
paragraph instead?  (fixes a couple  plurality issues and one transition issue):

   The contents of <intended> are related to the 'config true'
   subset of <operational>, such that a client can determine to what
   extent the intended configuration is currently applied by checking
   whether the contents of <intended> also appear in <operational>.

3) I'm okay with this.

4) This is better.


Thanks,
Kent



On 9/11/17, 11:22 AM, "Robert Wilton" <rwilton@cisco.com<mailto:rwilton@cisco.com>> wrote:


As one of the authors, I would like to see a few minor editorial updates, described below.  Otherwise I believe that the document is ready for publication.

Proposed changes:

1. I think that the document could further emphasis that the schema for all the conventional datastores must be the same.

Old:

4.5.  Conventional Configuration Datastores

   The conventional configuration datastores are a set of configuration
   datastores that share a common schema, allowing data to be copied
   between them.  The term is meant as a generic umbrella description of
   these datastores.  The set of datastores include:

New:

4.5.  Conventional Configuration Datastores

   The conventional configuration datastores are a set of configuration
   datastores that all share exactly the same schema, allowing data to be copied
   between them.  The term is meant as a generic umbrella description of
   these datastores.  The set of datastores include:



2. I think that the description of the intended datastore could be expanded to give a bit more clarity.

OLD:

4.4.  The Intended Configuration Datastore (<intended>)

   The intended configuration datastore (<intended>) is a read-only
   configuration datastore.  It is tightly coupled to <running>.  When
   data is written to <running>, the data that is to be validated is
   also conceptually written to <intended>.  Validation is performed on
   the contents of <intended>.

   For simple implementations, <running> and <intended> are identical.

   <intended> does not persist across reboots; its relationship with
   <running> makes that unnecessary.

   ...

NEW:

4.4.  The Intended Configuration Datastore (<intended>)

   The intended configuration datastore (<intended>) is a read-only
   configuration datastore.  It represents the configuration after all
   configuration transformations to <running> are performed (e.g.
   template expansion, inactive configuration removal), and is the
   configuration that the system attempts to apply.

   It is tightly coupled to <running>.  When data is written to
   <running>, the data that is to be validated is also conceptually
   written to <intended>.  Validation is performed on the contents of
   <intended>.

   For simple implementations, <running> and <intended> are identical.

   The contents of <intended> is also related to the 'config true'
   subset of <operational>, and hence a client can determine to what
   extent the intended configuration is currently applied by checking
   whether the contents of <intended> also appears in <operational>.

   <intended> does not persist across reboots; its relationship with
   <running> makes that unnecessary.

   ...

3. I think that it may aid readability if the section on conventional configuration datastores was moved above the description of the individual conventional configuration datastores, which could then be intended one level.  Best illustrated via the change to the table of contents.

E.g. current TOC:

   4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
     4.1.  The Startup Configuration Datastore (<startup>) . . . . .   9
     4.2.  The Candidate Configuration Datastore (<candidate>) . . .  10
     4.3.  The Running Configuration Datastore (<running>) . . . . .  10
     4.4.  The Intended Configuration Datastore (<intended>) . . . .  10
     4.5.  Conventional Configuration Datastores . . . . . . . . . .  11
     4.6.  Dynamic Configuration Datastores  . . . . . . . . . . . .  11
     4.7.  The Operational State Datastore (<operational>) . . . . .  11
       4.7.1.  Remnant Configuration . . . . . . . . . . . . . . . .  12
       4.7.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
       4.7.3.  System-controlled Resources . . . . . . . . . . . . .  13
       4.7.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  13

Proposed TOC:

   4.  Architectural Model of Datastores . . . . . . . . . . . . . .   8
     4.1.  Conventional Configuration Datastores . . . . . . . . . .   9
       4.1.1.  The Startup Configuration Datastore (<startup>) . . .  10
       4.1.2.  The Candidate Configuration Datastore (<candidate>) .  10
       4.1.3.  The Running Configuration Datastore (<running>) . . .  10
       4.1.4.  The Intended Configuration Datastore (<intended>) . .  11
     4.2.  Dynamic Configuration Datastores  . . . . . . . . . . . .  12
     4.3.  The Operational State Datastore (<operational>) . . . . .  12
       4.3.1.  Remnant Configuration . . . . . . . . . . . . . . . .  13
       4.3.2.  Missing Resources . . . . . . . . . . . . . . . . . .  13
       4.3.3.  System-controlled Resources . . . . . . . . . . . . .  14
       4.3.4.  Origin Metadata Annotation  . . . . . . . . . . . . .  14

4. Finally, I noticed one reference that could be improved, by changing it from "(described below)" to a proper section reference:

647,648c644,645
<    circumstances, e.g., an abnormal value is 'in use', or due to remnant
<    configuration (described below).  Note, that deviations are still
---
>    circumstances, e.g., an abnormal value is "in use", or due to remnant
>    configuration (see Section 4.7.1).  Note, that deviations are still

Thanks,
Rob


On 01/09/2017 22:02, Lou Berger wrote:

All,



This starts a two week working group last call on

draft-ietf-netmod-revised-datastores-04.



The working group last call ends on September 17.

Please send your comments to the netmod 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.



Thank you,

Netmod Chairs