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

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 12 June 2018 12:36 UTC

Return-Path: <mjethanandani@gmail.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 98BC2130E27; Tue, 12 Jun 2018 05:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 T2ulAczizolB; Tue, 12 Jun 2018 05:36:43 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 8EFBD130EE4; Tue, 12 Jun 2018 05:36:41 -0700 (PDT)
Received: by mail-oi0-x233.google.com with SMTP id t133-v6so20906605oif.10; Tue, 12 Jun 2018 05:36:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0HzhPi3UbP7R7jL+0YLr4HZDI6dzFv6h4/UGdr16rjo=; b=A99wpXc70D+EM/CFhJ5r1YqcdUFVWJ+oY1o/xGaKg3/uuL++8XqUk6MiNrJ4EnSeAk KjTU8elmZv6C8jlZNEzck/4RoDAbVE2grGLQAe+PtqYljK7JzZeP0uNEMc01Pd8CH677 +Pq0fa2DRjj7+hLTW4nZLLxPA5R3QpxvTe26I6JNFyXwY3Ls6zbNeeP3XEPj0BPI0zjA FS6kBYFAZ3kmwe6FUNljvTlh9Xag9dCn9PHivbIzcElS59bq6PmNj+YRALN03aTZ4fe9 W9eQbPBJX+s3JQ7NTjyHwVaVUVrlXKiAD+sR9gT8tQoREFXJOkzo9W8sIdvxuV1nXpZg mkxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0HzhPi3UbP7R7jL+0YLr4HZDI6dzFv6h4/UGdr16rjo=; b=Di7ZF1hPBo+fw/Wk9InWcm+k6Cqx2HjID3eAsxhq+NggzShzy8KVDEC95yeUQmI2e2 Eh/1Q+AD0Oo3Q/0CbNdD2m3c/nVR9iBd9+A5XI645xSVMxeYRyzaTubM+wgBG8msx7hS JeltV2Cq3I3eDyeF0+VQPNFtTYtq+jgAe2EiHfHqjGNhS6tl79z0JYeykh/EJ0ukJOeT eKFX01jFgTeggSDdVQ+ihtsIOHQ7oyd2g9ruMWtLiflMMclqgheLJwaM5mWP4i1lbLpt 06pDi+q2POQQTPcFs98/ZhBHTMQ3mxViEIn5G/laQIAOUe8h+smPMZEWeqiXTcRh21ky iZ8A==
X-Gm-Message-State: APt69E3FP3ZwDGI3u9Qstkndi2ysb+fOf2rCDQ2Tso+ql9C8l9K4iQP4 lmq7UJ0yUOJPiemLi63+n30=
X-Google-Smtp-Source: ADUXVKIjX2G0RXV/TaMKef0f1byRW8PfjppCgAx3ktX4CaXVqz22FZQvCpEl7oQadRB5ZtIrs2WPZw==
X-Received: by 2002:aca:a88b:: with SMTP id r133-v6mr1939269oie.213.1528807000802; Tue, 12 Jun 2018 05:36:40 -0700 (PDT)
Received: from [10.155.111.35] ([198.24.6.219]) by smtp.gmail.com with ESMTPSA id 68-v6sm31030ott.24.2018.06.12.05.36.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jun 2018 05:36:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <224028b2-59c5-6859-0e2a-331ed48121ec@cisco.com>
Date: Tue, 12 Jun 2018 08:36:47 -0400
Cc: Martin Bjorklund <mbj@tail-f.com>, Netconf <netconf@ietf.org>, draft-ietf-netconf-nmda-netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D42566D9-0C25-468E-B90F-B15589A7FB6D@gmail.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BBB4569@dggeml510-mbx.china.huawei.com> <a497b165-1f78-2d2f-9563-01fbb39619df@cisco.com> <20180604.121748.1873023460220711310.mbj@tail-f.com> <224028b2-59c5-6859-0e2a-331ed48121ec@cisco.com>
To: Robert Wilton <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/k-PXCzkn9WO0FB9eozvKzZvX5nc>
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: Tue, 12 Jun 2018 12:36:48 -0000

Have the authors agreed on the final set of edits for this document? How about the example that Rohit mentioned in the original e-mail?

> On Jun 4, 2018, at 7:01 AM, Robert Wilton <rwilton@cisco.com> wrote:
> 
> 
> 
> On 04/06/2018 11:17, Martin Bjorklund wrote:
>> 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".
> OK.
> 
>> 
>>> +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?
> I think that it is confusing, and probably depends on how you read it.
> 
> But, if you are OK with "any" then I think that reads better and is more intuitive.
> 
> Thanks,
> Rob
> 
> 
> 
>> 
>> 
>> /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
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com