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

Martin Bjorklund <mbj@tail-f.com> Mon, 11 September 2017 17:31 UTC

Return-Path: <mbj@tail-f.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 F3D0A13318D for <netmod@ietfa.amsl.com>; Mon, 11 Sep 2017 10:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 FJBmI9CMZ4pl for <netmod@ietfa.amsl.com>; Mon, 11 Sep 2017 10:31:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BE11613318C for <netmod@ietf.org>; Mon, 11 Sep 2017 10:31:17 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id AD8A01AE0403; Mon, 11 Sep 2017 19:31:16 +0200 (CEST)
Date: Mon, 11 Sep 2017 19:31:24 +0200 (CEST)
Message-Id: <20170911.193124.713501339751798550.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: rwilton@cisco.com, lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <E1A72908-D7D6-4FDF-BF77-8E6B0D2CFB4B@juniper.net>
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net> <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com> <E1A72908-D7D6-4FDF-BF77-8E6B0D2CFB4B@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Wzc9ywBLrFldS3lqVfTQ1Nd0QbQ>
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:31:20 -0000

Kent Watsen <kwatsen@juniper.net> wrote:
> 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


Or just remove "all".

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

Ok.

> 3) I'm okay with this.

I agree that the proposed TOC changes are better.

> 4) This is better.

Agreed.


/martin


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