[netmod] AD review: draft-ietf-netmod-revised-datastores-08

Benoit Claise <bclaise@cisco.com> Wed, 20 December 2017 16:40 UTC

Return-Path: <bclaise@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 158D8124B17; Wed, 20 Dec 2017 08:40:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, 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 KF4hX6svbI8T; Wed, 20 Dec 2017 08:40:35 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E891200FC; Wed, 20 Dec 2017 08:40:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9009; q=dns/txt; s=iport; t=1513788034; x=1514997634; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=c40y9a8iw2HI8b8cgJYDsgvgGzfZOQu0fC/tHzDpC78=; b=nBnAQ0NGnmFbr4ghMTBYKHk9DQxbJnDdBFFR093/UO3JjcDA5eZpZAA0 X+idC7dNZggtOihVfvmcNPgAZQD8vnTIfrkTxZUhEdFjC5ce+ZH377DRf t2ikepHuDJyCRqcalIj6m0/pWfiySRAAghn0WTEHoUDWsXHSrr54QKCdl k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAwBhkTpa/xbLJq1SCRoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGEJHSELYsVj2oMkXyFUBSCAQofhRwChVQXAQEBAQEBAQEBayiFJAY?= =?us-ascii?q?jBGJNAgJXBgEMCAEBiicQpGmBbTomikMBAQEBAQEBAQIBAQEBAQEBARsFg3+Da?= =?us-ascii?q?IISC4YnAYE2DoNAgmMFik6HTpEoiACDcYk9gheKASSHPI0egVmIBYE7IAE3gU8?= =?us-ascii?q?yGggbFYJmhFdAiFQsghsBAQE?=
X-IronPort-AV: E=Sophos;i="5.45,432,1508803200"; d="scan'208,217";a="1051553"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2017 16:40:30 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBKGeUwa032676; Wed, 20 Dec 2017 16:40:30 GMT
References: <e2fd599f-7547-d2f7-d450-f67a3f409ae1@cisco.com>
From: Benoit Claise <bclaise@cisco.com>
To: NETMOD Working Group <netmod@ietf.org>, "draft-ietf-netmod-revised-datastores@ietf.org" <draft-ietf-netmod-revised-datastores@ietf.org>
X-Forwarded-Message-Id: <e2fd599f-7547-d2f7-d450-f67a3f409ae1@cisco.com>
Message-ID: <fe856e5c-5760-9bb9-ace3-cec0cfb39278@cisco.com>
Date: Wed, 20 Dec 2017 17:40:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <e2fd599f-7547-d2f7-d450-f67a3f409ae1@cisco.com>
Content-Type: multipart/alternative; boundary="------------961B34A367DCC7E01FBE1467"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ANw_adolsvTSpmn9-Fp8kutWj4Q>
Subject: [netmod] AD review: draft-ietf-netmod-revised-datastores-08
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: Wed, 20 Dec 2017 16:40:37 -0000

Dear all,

In order not to be the bottleneck in the process and assuming that the 
document will be in "publication requested" pretty soon, here is my AD 
review of draft-ietf-netmod-revised-datastores-08

-


        5.3.2. Missing Resources

    Configuration in <intended> can refer to resources that are not
    available or otherwise not physically present.  In these situations,
    these parts of <intended> are not applied.  The data appears in
    <intended> but does not appear in <operational>.


I understand what you want to say.
Let me take an example. I have a router with a Line Card configured and 
working well. if I remove the LC, the configuration should still be in 
the <running> and <intended> but not in <operational>.
However, based on figure below, the notion of "inactive" nodes might be 
misleading. Indeed, people might read that the LC is inactive, so the LC 
configuration should not be in <intended>

      +-------------+                 +-----------+
      | <candidate> |                 | <startup> |
      |  (ct, rw)   |<---+       +--->| (ct, rw)  |
      +-------------+    |       |    +-----------+
             |           |       |           |
             |         +-----------+         |
             +-------->| <running> |<--------+
                       | (ct, rw)  |
                       +-----------+
                             |
                             |        // configuration transformations,
                             |        // e.g., removal of "inactive"
                             |        // nodes, expansion of templates
                             v
                       +------------+
                       | <intended> | // subject to validation
                       | (ct, ro)   |
                       +------------+

I understand that "inactive nodes" has a different meaning.

Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"

- In the C.1 example,

    <system
        xmlns="urn:example:system"
        xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">

      <hostname or:origin="or:dynamic">bar</hostname>

      <interface or:origin="or:intended">
        <name>eth0</name>
        <auto-negotiation>
          <enabled or:origin="or:default">true</enabled>
          <speed>1000</speed>
        </auto-negotiation>
        <speed>100</speed>
        <address>
          <ip>2001:db8::10</ip>
          <prefix-length>64</prefix-length>
        </address>
        <address or:origin="or:dynamic">
          <ip>2001:db8::1:100</ip>
          <prefix-length>64</prefix-length>
        </address>
      </interface>

I guess it "or:dynamic" should be replaced by "or:learned"

Justification:

      identity learned {
        base origin;
        description
          "Denotes configuration learned from protocol interactions with
           other devices, instead of via either the intended
           configuration datastore or any dynamic configuration
           datastore.

           Examples of protocols that provide learned configuration
           include link-layer negotiations, routing protocols,_and DHCP._";


_Editorial:_

- number the figures

- section 8.2
    This document registers two YANG modules in the YANG Module Names
    registry [RFC6020 <https://tools.ietf.org/html/rfc6020>].  Following the format in [RFC6020 <https://tools.ietf.org/html/rfc6020>], the the
    following registrations are requested:

duplicated "the the"
  
Regards, Benoit (OPS AD)