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

[Martin Bjorklund <[e-mail]>]

Hi,

Mahesh Jethanandani <[e-mail]> wrote:
> Hi Rohit,
> 
> I believe we were past LC and into the IESG queue by the time
> consensus was reached here. Therefore, we had held off making the
> changes, and make them as part of IESG review. That time would be now.
> 
> There was consensus on the change in text in Section 3.1.1, in the
> description statements in the model, and a request by chairs to upload
> the changes to GitHub.
> On the example, there was consensus, after it
> was fixed for namespace, but there was an open question of where to
> place the example. I had suggested Appendix, but I am open to anywhere
> else. Can we get agreement on it?

We fixed all these ~ two months ago and pushed to github.  The new
example I added is:

3.1.1.4.  Example: Retrieving a filtered subtree from <operational>

   The following example shows how the "origin-filter" can be used to
   retrieve nodes from <operational>.  The example uses the fictional
   data model defined in Appendix C of [RFC8342].

   <rpc message-id="102"
        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:operational</datastore>
       <subtree-filter>
         <bgp xmlns="http://example.com/ns/bgp"/>
       </subtree-filter>
       <origin-filter>or:intended</origin-filter>
       <origin-filter>or:system</origin-filter>
       <with-origin/>
     </get-data>
   </rpc>

   <rpc-reply message-id="102"
       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/bgp"
            xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
            or:origin="or:intended">
         <peer>
           <name>2001:db8::2:3</name>
           <local-port or:origin="or:system">60794</local-port>
           <state>established</state>
         </peer>
       </bgp>
     </data>
   </rpc-reply>



/martin


> 
> Thanks.
> 
> > On Sep 27, 2018, at 8:01 PM, Rohit R Ranade <[e-mail]>
> > wrote:
> > 
> > Hi All,
> > 
> > Can we add the below change to the ietf-netconf-nmda-netconf draft ? 
> > 
> > With Regards,
> > Rohit R Ranade
> > 
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> > [mailto:[e-mail]]
> > Sent: 25 June 2018 13:37
> > To: Rohit R Ranade <[e-mail]>
> > Cc: Kent Watsen <[e-mail]>; Mahesh Jethanandani
> > <[e-mail]>; Netconf <[e-mail]>;
> > [e-mail]
> > Subject: Re: [Netconf] Editorial change-2 for
> > draft-ietf-netconf-nmda-netconf
> > 
> > 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:[e-mail]]
> >> Sent: 19 June 2018 03:43
> >> To: Juergen Schoenwaelder <[e-mail]>; 
> >> Rohit R Ranade <[e-mail]>
> >> Cc: Mahesh Jethanandani <[e-mail]>; Netconf 
> >> <[e-mail]>; [e-mail]
> >> 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:[e-mail]] On Behalf Of Juergen 
> >>> Schoenwaelder
> >>> Sent: 13 June 2018 15:57
> >>> To: Mahesh Jethanandani <[e-mail]>
> >>> Cc: Netconf <[e-mail]>;
> >>> [e-mail]
> >>> 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 <[e-mail]> wrote:
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> On 04/06/2018 11:17, Martin Bjorklund wrote:
> >>>>>> Hi
> >>>>>> 
> >>>>>> Two comments inline.
> >>>>>> 
> >>>>>> Robert Wilton <[e-mail]> 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
> >>>>>>>> [e-mail]
> >>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf
> >>>>>>>> .o 
> >>>>>>>> rg_mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0Uj
> >>>>>>>> BX 
> >>>>>>>> eMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJ
> >>>>>>>> dc 
> >>>>>>>> Zo&m=EhfhSrolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyB
> >>>>>>>> W_ -8ddOVCtKfjteIxUz56Qf08hiQBzQ3I&e=
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [e-mail]
> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.or
> >>>>> g_ 
> >>>>> mailman_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> >>>>> nd 
> >>>>> b3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=Eh
> >>>>> fh 
> >>>>> Srolqk6RiObTfkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKf
> >>>>> jt
> >>>>> eIxUz56Qf08hiQBzQ3I&e=
> >>>> 
> >>>> Mahesh Jethanandani
> >>>> [e-mail]
> >>>> 
> >>> 
> >>> -- 
> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax: [phone]
> >>> <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
> >>> [e-mail]
> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma
> >>> il 
> >>> man_listinfo_netconf&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDT
> >>> Xc 
> >>> WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=EhfhSrolqk6RiO
> >>> bT 
> >>> fkH3FMcR_uv8jGD-SWToO3mqxo8&s=PFBleMrQyBW_-8ddOVCtKfjteIxUz56Qf08hiQ
> >>> Bz
> >>> Q3I&e=
> >> 
> >> -- 
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax: [phone]
> >> <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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> Mahesh Jethanandani
> [e-mail]
> 
> 
>