[netmod] XPath questions about revised datastores

Andy Bierman <andy@yumaworks.com> Wed, 14 June 2017 18:07 UTC

Return-Path: <andy@yumaworks.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 83168128AB0 for <netmod@ietfa.amsl.com>; Wed, 14 Jun 2017 11:07:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 x42449kWZ8rC for <netmod@ietfa.amsl.com>; Wed, 14 Jun 2017 11:07:38 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598FD127866 for <netmod@ietf.org>; Wed, 14 Jun 2017 11:07:38 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id 36so11264706wry.3 for <netmod@ietf.org>; Wed, 14 Jun 2017 11:07:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0V6q6erfobjDqw9pJkVOUVnK/rLiE4W2PJhzb5rUes8=; b=YBsPxRdivIfBePnkBfi8TfLc1zmr8tSpSMBMI1afDfw67/tM8daUhq29gUbL0yW9xz gLl7MW+8GNQn444K0DOv3AjP4EU52PvGCPcowI0JoBp7MGVckhdsvOL/JL3npYVRImTp MqODnMpnsTQoyW4o4Z32JNJIMxSKVyoFrxqOQOVJSSN8rSxEiV8LdD2zHGAHAHtBSjug fHDBjG+gpMy8ujUoevwLOyNq25aoaYDgJpROKLZcgFgLjM8bs3KpxeQ6tCvQPNLlq2Qw VeVLKTrJ6Rl7Hmm2QewO5WiW4nUNxrJvhanifcoFuABhyONrAo2kyQlkoLkFr+upkUD8 aZYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0V6q6erfobjDqw9pJkVOUVnK/rLiE4W2PJhzb5rUes8=; b=QfJ8CtnP3a0siQFVXisITpMoY02dvtWwsWEoMKpnffmSa1FhH2FL8gfdoS62Tq+9Nk mxWgZQTIixKNrPQVJCXqpniyEYDbCfqGHUNzvxhZj5dgmJERvYVskvVlP9MxRmZ/Jb+O 7Bb+PNsXKaOoFTs/AASBcAvmdvbFRgzG0naEJh4objapA8fnXIcOXhopniJ8Cx9AbTci qlyJoDyGaWAqQvj7ErXkkBi917YEPUdNqnRvg8urYQwD8HgwfpUiH74qTCfTuOxoxwzr gO99+tjcH9PkukHFJvUWdulIWLuITotnfyixiJzyzJkqGkTKP2R7viYJ5zwB1s/odwzA XPxA==
X-Gm-Message-State: AKS2vOyzuFh9vmLwJpiFqJ3GOfJOJJ2RUk3ZfgNUYHUiZ8rFpGC+uQA2 JjGe2Vi2Tv7LUrLtZsUCa1WLPk2CNse/KOE=
X-Received: by 10.28.151.207 with SMTP id z198mr931187wmd.48.1497463656568; Wed, 14 Jun 2017 11:07:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.182.173 with HTTP; Wed, 14 Jun 2017 11:07:35 -0700 (PDT)
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 14 Jun 2017 11:07:35 -0700
Message-ID: <CABCOCHS1oFGZMzDRANhdRrH1S+75RNbgdDggqW84ee7uwd5fbQ@mail.gmail.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144ea2a50780e0551ef6d3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OZa8Xa5B0ZyXXPudDrpIcV6HqI0>
Subject: [netmod] XPath questions about revised datastores
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, 14 Jun 2017 18:07:40 -0000

Hi,

I don't know if getting rid of /foo-state is such a great idea,
especially wrt/ counters and other objects that are not
related to intended config vs. applied config.

Q1) how does a client know the difference between an auto-generated
foo-state.yang and a real foo-state.yang?  Seem like a YANG extension
is needed to flag an auto-generated foo-state.yang

Q2) How does XPath reference an operational node if the /foo-state
subtree has been moved to the /foo config subtree?

module foo {

     container foo {
          leaf stat-collect-type {
             type enumeration {
               enum stat-set1;
               enum stat-set2;
             }
           }
      }

     container foo-state {
          config false;
          leaf stat-collect-type {
             type enumeration {
               enum stat-set1;
               enum stat-set2;
             }
           }
           container stat-set1 {
              when "../stat-collect-type = 'stat-set1'";
              ...
           }
           container stat-set2 {
              when "../stat-collect-type = 'stat-set2'";
              ...
           }
     }
}

In this example, there is a request stat collect type /foo/stat-collect-type
and there is an operational value (what the server/device is capable
of collecting -- e.g. client requests stat-set2 knowing the server
will change it to stat-set1 if set2 not supported)

So if /foo-state is folded into /foo (because that is the intent -- to get
rid of this extra stat-collect-type leaf), then how do the when-stmts
get applied to the operational value instead of the configured value?
The same issue applies if the when-stmts are within an augment-stmt

WANT:

 augment /foo-state {
    when "stat-collect-type = 'stat-set1'";
    container stat-set1 {
       ...
    }
 }

RD Provides:

  augment /foo {
    when "stat-collect-type = 'stat-set1'";
    container stat-set1 {
       config false;
       ...
    }
 }

There is no way to use when-stmt to reference the operational value.
This is a rather common usage of the when-stmt, so it should not
be removed if RD is used.



Andy