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

[Mahesh Jethanandani <[e-mail]>]

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?

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]