Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf

Martin Bjorklund <mbj@tail-f.com> Mon, 04 June 2018 10:17 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EBF126BF6; Mon, 4 Jun 2018 03:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 tk3weSu_iMnt; Mon, 4 Jun 2018 03:17:50 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02686126579; Mon, 4 Jun 2018 03:17:50 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 832801AE0309; Mon, 4 Jun 2018 12:17:48 +0200 (CEST)
Date: Mon, 04 Jun 2018 12:17:48 +0200 (CEST)
Message-Id: <20180604.121748.1873023460220711310.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: rohitrranade@huawei.com, netconf@ietf.org, draft-ietf-netconf-nmda-netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com> <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GRf1hATNB8TGEz_z4CnOwD6WDFM>
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jun 2018 10:17:53 -0000

Hi

Two comments inline.

Robert Wilton <rwilton@cisco.com> wrote:
> Hi Rohit, authors,
> 
> I think that these are valid clarifications. I've reworded them
> slightly, and moved the ancestor node text to the YANG module
> instead.  I also think that the ancestor node text generically covers
> the config filter clarification that you raised previously.
> 
> Hence, I propose the following diff to the NETCONF NMDA draft:
> 
> rwilton@rwilton-lnx:~/netconf-wg/netconf-nmda$ git diff --staged
> diff --git a/ietf-netconf-nmda.yang b/ietf-netconf-nmda.yang
> index f2929b9..72a674a 100644
> --- a/ietf-netconf-nmda.yang
> +++ b/ietf-netconf-nmda.yang
> @@ -105,6 +105,9 @@ module ietf-netconf-nmda {
>         by get-data must satisfy all filters, i.e., the filter
>         criteria are logically ANDed.
> 
> +       Any ancestor nodes (including list keys) of nodes matched by
> +       the filter are included in the response.
> +
>         The 'with-origin' parameter is only valid for an operational
>         datastore. If 'with-origin' is used with an invalid datastore,
>         then the server MUST return an <rpc-error> element with an
> @@ -193,7 +196,7 @@ module ietf-netconf-nmda {
>            description
>              "Filter based on the 'origin' annotation.  A node matches
>               the filter if its 'origin' annotation is not derived
> -             from and not equal to all of the given filter values.";
> +             from and not equal to any of the given filter values.";
>          }
>        }
> 
> diff --git a/nmda-netconf.org b/nmda-netconf.org
> index e44e2c7..100e173 100644
> --- a/nmda-netconf.org
> +++ b/nmda-netconf.org
> @@ -129,14 +129,17 @@ The "config-filter" parameter can be used to
> retrieve only "config
>  true" or "config false" nodes.
> 
>  The "origin-filter" parameter, which can be present multiple times,
> -selects nodes matching any of the given values. The
> -"negated-origin-filter", which can be present multiple times, selects
> -nodes that do not match all given values. The "origin-filter"
> -and "negated-origin-filter" parameters cannot be used together.
> +selects nodes with origins matching, or derived from, any of the
> given

I would prefer:

 selects nodes with origins equal to, or derived from, any of the
 given


IMO, the term "match" in the original text means "equal to or
derived-from", as explained in the data model.

The term "match" is problematic unless it is explained, b/c some
people will think it means "equal to".  (Noone will think that
"matches the regular expression" means "equal to the regular
expression" though...)

Conclusion: always avoid the term "match".

> +values. The "negated-origin-filter", which can be present multiple
> +times, selects nodes with origins that do not match, and are not
> +derived from, any of the given values. The "origin-filter" and
> +"negated-origin-filter" parameters cannot be used together.
> 
>  The "max-depth" parameter can be used by the client to limit the
>  number of sub-tree levels that are returned in the reply.
> 
> Note to the authors, for the negative-origin-filter, I've also changed
> "all" to "any" (which changes the semantics, but I think it was wrong
> before).

Agree that "any" is correct.

But does it really change the semantics?  "all" sounds quite odd, but
isn't the end result the same?


/martin


> 
> Similar updates will need to also be done to RESTCONF, but let's agree
> the NETCONF text first.
> 
> Thanks,
> Rob
> 
> 
> On 01/06/2018 10:10, Rohit R Ranade wrote:
> >
> > Hi All,
> >
> > Section 3.1.1
> >
> > OLD:
> >
> >    The "origin-filter" parameter, which can be present multiple times,
> >
> >    selects nodes matching any of the given values.  The
> >
> > "negated-origin-filter", which can be present multiple times, selects
> >
> >    nodes that do not match all given values.
> >
> > NEW:
> >
> > The "origin-filter" parameter, which can be present multiple times,
> >
> >    selects nodes which are derived from or matching any of the given
> > values.  The
> >
> > "negated-origin-filter", which can be present multiple times, selects
> >
> >    nodes which are not derived from and do not match all given values.
> >
> > When a data-node matching the filter is selected, the configuration
> > ancestors
> >
> > (if any) and list key leafs (if any), even if they do not match the
> > filter, are also returned.
> >
> > Consider two origins such as “learned” and “derived-from-learned”.
> >
> > “derived-from-learned” is derived from learned origin.
> >
> > Using the origin filters it is not possible to get nodes belonging to
> > “learned”
> >
> > only as the nodes of derived origin are automatically selected.
> >
> > Notes:
> >
> > The text in 3.1.1 did not include the “derived-from” logic for
> > selection , while in the data-model definition it was present.
> >
> >  We can also add clarification about the ancestor and key being
> > output, even if though they do match the filter, since the leaf
> >
> > matches the filter.
> >
> > Example : We can use the RFC 8342 Appendix C.2 BGP Example
> >
> >    <rpc message-id="101"
> >
> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >
> >      <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
> >
> > xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
> >
> > <datastore>ds:running</datastore>
> >
> > <subtree-filter>
> >
> >          <bgp xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/>
> >
> >       </subtree-filter>
> >
> > <negated-origin-filter>intended</negated-origin-filter>
> >
> > <with-origin>true</with-origin>
> >
> >      </get-data>
> >
> > </rpc>
> >
> >    <rpc-reply message-id="101"
> >
> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >
> >      <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
> >
> >       <bgp xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
> >
> > or:origin="or:intended">
> >
> >        <peer>
> >
> > <name>2001:db8::2:3</name>
> >
> >          <local-as or:origin="or:default">64501</local-as>
> >
> >          <peer-as or:origin="or:default">64502</peer-as>
> >
> >          <local-port or:origin="or:system">60794</local-port>
> >
> >          <remote-port or:origin="or:default">179</remote-port>
> >
> > <state>established</state>
> >
> >        </peer>
> >
> >       </bgp>
> >
> >      </data>
> >
> >    </rpc-reply>
> >
> > With Regards,
> >
> > Rohit R Ranade
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>