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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 25 June 2018 08:07 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 C9D711292F1; Mon, 25 Jun 2018 01:07:19 -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] 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 2WVXvtiQM5er; Mon, 25 Jun 2018 01:07:16 -0700 (PDT)
Received: from anna.localdomain (anna.eecs.jacobs-university.de [IPv6:2001:638:709:5::7]) by ietfa.amsl.com (Postfix) with ESMTP id BD8E3130934; Mon, 25 Jun 2018 01:07:15 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 11544228DB5C; Mon, 25 Jun 2018 10:07:14 +0200 (CEST)
Date: Mon, 25 Jun 2018 10:07:14 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Rohit R Ranade <rohitrranade@huawei.com>
Cc: Kent Watsen <kwatsen@juniper.net>, Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>, "draft-ietf-netconf-nmda-netconf@ietf.org" <draft-ietf-netconf-nmda-netconf@ietf.org>
Message-ID: <20180625080714.kg2h66mxc7kpgtgs@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Rohit R Ranade <rohitrranade@huawei.com>, Kent Watsen <kwatsen@juniper.net>, Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>, "draft-ietf-netconf-nmda-netconf@ietf.org" <draft-ietf-netconf-nmda-netconf@ietf.org>
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> <D42566D9-0C25-468E-B90F-B15589A7FB6D@gmail.com> <20180613102721.tnqufeommaojdwm2@anna.jacobs.jacobs-university.de> <991B70D8B4112A4699D5C00DDBBF878A6BBBD928@dggeml510-mbx.china.huawei.com> <20180613120742.7xfgwy66jq6qxsmf@anna.jacobs.jacobs-university.de> <8AEB4F37-A148-428F-A5C0-1AB836F0733E@juniper.net> <991B70D8B4112A4699D5C00DDBBF878A6BBC062A@dggeml510-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BBC062A@dggeml510-mbx.china.huawei.com>
User-Agent: NeoMutt/20180512
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/tmXTe_k0Y8-R0NMafBdUxrscbbI>
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: Mon, 25 Jun 2018 08:07:20 -0000

This seems to be correct as far as I can tell. I am not sure what
exactly the changes are (i.e., where this is supposed to go) and I
think the document shephered should probably coordinate this as we
are now moving to IETF last call (once the details have been worked
out, we could for example treat this as IETF last call comment).

/js

On Tue, Jun 19, 2018 at 05:25:37AM +0000, Rohit R Ranade wrote:
> I agree with Juergen's comments. Only exception is that "intended" for " negated-origin-filter" will be qualified by the ietf-origin namespace.
> Please find the updated 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"
>                xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
>        <datastore>ds:running</datastore>
>        <subtree-filter>
>          <bgp xmlns="http://example.com/ns/example"/>
>       </subtree-filter>
>        <negated-origin-filter>or:intended</negated-origin-filter>
>        <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="http://example.com/ns/example" 
>           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
> 
> -----Original Message-----
> From: Kent Watsen [mailto:kwatsen@juniper.net] 
> Sent: 19 June 2018 03:43
> To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Rohit R Ranade <rohitrranade@huawei.com>
> Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; Netconf <netconf@ietf.org>; draft-ietf-netconf-nmda-netconf@ietf.org
> Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf
> 
> Let's conclude this thread and push an update (or updatres) to GitHub, so the update doesn't get lost as we head into the IESG LC.
> 
> Two items:
>   - "origin-filter" parameter
>   - <get-data> usage example 
> 
> Kent and Mahesh
> 
> 
> ===== original message =====
> 
> Yes, for bgp there is no namespace defined in the example in RFC 8342. Using ietf-netconf-nmda clearly is misleading, a fictional example namespace will be better.
> 
> I think the lexical representation of the value 'intended' requires to be namespace qualified, i.e. 'ds:intended'.
> 
> The with-origin is defined to be of type empty - there is no 'true'
> value or something like that, its just <with-origin/>.
> 
> /js
> 
> On Wed, Jun 13, 2018 at 11:20:21AM +0000, Rohit R Ranade wrote:
> > Hi Juergen,
> > 
> > Can you please identify the namespaces which are not OK so that we can fix them. 
> > For want of a namespace for "bgp", I re-used the ietf-netconf-nmda namespace as it is just an example. We can use the "https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_ns_example&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=tm-DrFSVrRkMzAH-DiWECrNBbWhSmbKnBauKdzx3J-k&e=" namespace instead.
> > 
> > With Regards,
> > Rohit R Ranade
> > 
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen 
> > Schoenwaelder
> > Sent: 13 June 2018 15:57
> > To: Mahesh Jethanandani <mjethanandani@gmail.com>
> > Cc: Netconf <netconf@ietf.org>; 
> > draft-ietf-netconf-nmda-netconf@ietf.org
> > Subject: Re: [Netconf] Editorial change-2 for 
> > draft-ietf-netconf-nmda-netconf
> > 
> > I am not sure an example is needed but if we include one, we need one which is correct. I think the namespaces are a bit messed up in Rohit's example.
> > 
> > /js
> > 
> > On Tue, Jun 12, 2018 at 08:36:47AM -0400, Mahesh Jethanandani wrote:
> > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.o
> > > >>>> rg_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBX
> > > >>>> eMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdc
> > > >>>> Zo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_
> > > >>>> -8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e=
> > > > 
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_
> > > > mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-nd
> > > > b3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Ehfh
> > > > Srolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjt
> > > > eIxUz56Qf08hiQBzQ3I&e=
> > > 
> > > Mahesh Jethanandani
> > > mjethanandani@gmail.com
> > > 
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=VZh0-GgZ6GpKnZhdi09mezzyPA62WEHUd5wPYbUVCI4&e=>
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXc
> > WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObT
> > fkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBz
> > Q3I&e=
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=VZh0-GgZ6GpKnZhdi09mezzyPA62WEHUd5wPYbUVCI4&e=>
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>