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

From: Rohit R Ranade <[email-masked]>
Date: Fri, 1 Jun 2018 09:10:34 +0000

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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 1 Jun 2018 17:22:16 +0100

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
+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).

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:
> 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”
>
> 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.
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Rohit R Ranade <[email-masked]>
Date: Mon, 4 Jun 2018 09:16:03 +0000

Hi Rob,

I am OK with the changes.
To enhance the understandability of the readers, please check if we can add an example in the draft for using the new filters, similar to the one I had given in my previous mail.

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:[email-masked]]
Sent: 01 June 2018 21:52
To: Rohit R Ranade <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf

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.

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.

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).

Similar updates will need to also be done to RESTCONF, but let's agree the NETCONF text first.

Thanks,
Rob

Section 3.1.1

OLD:

NEW:

Notes:

   <rpc message-id="101"

With Regards,
Rohit R Ranade

Netconf mailing list

[email-masked]<mailto:[email-masked]>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 04 Jun 2018 12:17:48 +0200 (CEST)

Hi

Two comments inline.

Robert Wilton <[email-masked]> wrote:
> 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.
> 

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".

> "all" to "any" (which changes the semantics, but I think it was wrong

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 4 Jun 2018 12:01:50 +0100

> Conclusion: always avoid the term "match".
OK.

> 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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 12 Jun 2018 08:36:47 -0400

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 <[email-masked]> wrote:
> 
> 
> 
> But, if you are OK with "any" then I think that reads better and is more intuitive.
> 
> Thanks,
> Rob
> 
> 
> 
>> 
>> 
>> /martin
>> 
>> 

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jun 2018 12:27:21 +0200

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

-- 
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/>

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 13 Jun 2018 11:20:21 +0000

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 "http://example.com/ns/example" namespace instead.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: 13 June 2018 15:57
To: Mahesh Jethanandani <[email-masked]>
Cc: Netconf <[email-masked]>; [email-masked]
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:
> >>> instead.  I also think that the ancestor node text generically 
> >>> covers the config filter clarification that you raised previously.
> >>> 
> >>> diff --git a/ietf-netconf-nmda.yang b/ietf-netconf-nmda.yang index 
> >>> f2929b9..72a674a 100644
> >>> +             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
> >>> 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"
> >>> +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.
> >>> 
> >>> 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).
> >> But does it really change the semantics?  "all" sounds quite odd, 
> >> but isn't the end result the same?
> >>>> Using the origin filters it is not possible to get nodes 
> >>>> belonging to “learned”
> >>>> 
> >>>>          <bgp 
> >>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"/>
> >>>> 
> >>>>       </subtree-filter>
> >>>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 13 Jun 2018 14:07:42 +0200

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:
> > >>>> times,
> > >>>> times,

---

From: Kent Watsen <[email-masked]>
Date: Mon, 18 Jun 2018 22:13:18 +0000

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 =====

/js

On Wed, Jun 13, 2018 at 11:20:21AM +0000, Rohit R Ranade wrote:
> 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
> 
> > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e=
> > > 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e=
> > 
> > Mahesh Jethanandani
> > [email-masked]
> > 
> 
> -- 
> 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=>
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&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=>

---

From: Rohit R Ranade <[email-masked]>
Date: Tue, 19 Jun 2018 05:25:37 +0000

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>

      <bgp xmlns="http://example.com/ns/example" 
          xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"

With Regards,
Rohit R Ranade

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: 19 June 2018 03:43
To: Juergen Schoenwaelder <[email-masked]>; Rohit R Ranade <[email-masked]>
Cc: Mahesh Jethanandani <[email-masked]>; Netconf <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Editorial change-2 for draft-ietf-netconf-nmda-netconf

Two items:

Kent and Mahesh

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'.

/js

On Wed, Jun 13, 2018 at 11:20:21AM +0000, Rohit R Ranade wrote:
> > >>>         then the server MUST return an <rpc-error> element with 
> > >>> an @@ -193,7 +196,7 @@ module ietf-netconf-nmda {
> > >>>            description
> > >>> @@ -129,14 +129,17 @@ The "config-filter" parameter can be used 
> > >>> to retrieve only "config  true" or "config false" nodes.
> > >>> 
> > >>> +selects nodes with origins matching, or derived from, any of 
> > >>> +the
> > >>> given
> > >> I would prefer:
> > >> 
> > >>> +multiple times, selects nodes with origins that do not match, 
> > >>> +and are not derived from, any of the given values. The 
> > >>>  The "max-depth" parameter can be used by the client to limit 
> > >>> the number of sub-tree levels that are returned in the reply.
> > >>> 
> > >>>>      <data 
> > >>>> xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
> > >>>> 
> > >>>> 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=
> > > 
> > > 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
> > [email-masked]
> > 
> 
> -- 
> 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=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jun 2018 10:07:14 +0200

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 26 Jun 2018 20:59:41 -0700

Hi Juergen,

> On Jun 25, 2018, at 1:07 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> exactly the changes are (i.e., where this is supposed to go)

Appendix?

> and I

BTW, there are corresponding changes for the clarification in nmda-restconf. Right?

Mahesh Jethanandani
[email-masked]