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

Robert Wilton <rwilton@cisco.com> Mon, 11 September 2017 15:22 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 132441330AE; Mon, 11 Sep 2017 08:22:18 -0700 (PDT)
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
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 ybbvg5DLtU8U; Mon, 11 Sep 2017 08:22:05 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4493C1330CE; Mon, 11 Sep 2017 08:22:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15945; q=dns/txt; s=iport; t=1505143324; x=1506352924; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xZU6XyBm4wT8sTKOGN32CAjH0xF4o8YtFpA4MgcNHBY=; b=HYT76g7uzMXRohVipsJWRdvpSxnE5eG59U4rBmCI145nVQH+9pjHChuw +ymUT78EzCGaTsS9HR3ou3pOLBR9aS2a1NiT+OPiUH8RPzP9qkZjwesha UbLJvu/ZmJcpUnrIAPz0DaQG5v6DC8ahLOLuwg93F2iRZjCVlyhu0p6Wt A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiBQDRqLZZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhS2EHosVkHYrkGqHUQqFPgKEZBQBAgEBAQEBAQFrKIUZAQUjSwQXCQI?= =?us-ascii?q?OCioCAlcGAQwIAQGKLY5HnWaCJyeKbwEBAQEBAQEBAgEBAQEBAQEBAQEBHYMrg?= =?us-ascii?q?1KCDguCcogKgmEFoHSUUYIThWeDWiSGeY1Xh1SBOTYhgQ0yIQgcFUqFGByBaD+?= =?us-ascii?q?HNiuCFAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,378,1500940800"; d="scan'208,217";a="655560569"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 15:22:02 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8BFM1ZK013527; Mon, 11 Sep 2017 15:22:01 GMT
To: Lou Berger <lberger@labn.net>, netmod WG <netmod@ietf.org>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, draft-ietf-netmod-revised-datastores@ietf.org
References: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <10476e00-0169-4258-449f-22cc7ca978a8@cisco.com>
Date: Mon, 11 Sep 2017 16:22:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <511deba5-34ca-dde2-6637-ceaf4c4af125@labn.net>
Content-Type: multipart/alternative; boundary="------------44A82F8743FBA67D4478B43D"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GKBv1DGqPmDscP7l9y-xeOfEaLo>
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 15:22:18 -0000

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