Subject: Re: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05

From: Rohit R Ranade <[email-masked]>
Date: Wed, 2 May 2018 11:28:42 +0000

Hi Juergen,

Some thoughts in-lined.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 25 April 2018 16:12
To: Rohit R Ranade <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] [netconf] Comments on draft-ietf-netconf-nmda-netconf-05

On Wed, Apr 25, 2018 at 04:22:24AM +0000, Rohit R Ranade wrote:
> Hi All,
> 
> I plan to implement this draft and hence had some implementation related clarifications.
> 
> 
> 1.       I feel that there should be more text added about "origin" filtering mechanism. I am not clear about some aspects of origin filtering.
> 
> RFC 8342 : NMDA RFC provides the below example
> 
> <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>                  or:origin="or:intended">
>        <interface>
>          <name>lo0</name>
>          <description>loopback</description>
>          <ip-address or:origin="or:system">127.0.0.1</ip-address>
>          <ip-address>::1</ip-address>
>        </interface>
>      </interfaces>
> If user provides <origin-filter> as "system" ONLY, then he will NOT get this record in output. Because the keys have originated from "intended" . Right ?
> So, If user wants to get the system originated data, he MUST give all the origins in the <origin-filter> where the keys of the system data have originated from. Can you please confirm whether this is OK.

I would expect that <origin-filter>or:system</origin-filter> would select the ip-address tagged with or:origin="or:system" and that the system would return any necessary container or list elements and the necessary key elements (since otherwise the value returned is just useless). So the result would be:

      <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                  or:origin="or:intended">
        <interface>
          <name>lo0</name>
          <ip-address or:origin="or:system">127.0.0.1</ip-address>
        </interface>
      </interfaces>

[Rohit R Ranade] While this looks OK for the origin filter, for the negated-origin-filter, for the same example given above, if <negated-origin-filter> or:intended<negated-origin-filter> is given, then it will give the "system" related nodes even if it encountered the "intended" node first, which the user definitely dint want included in the output ? Can you please confirm whether this is OK.
   Can you please clarify whether the negated filter has higher priority than the selected filter ?

> Another example given in RFC 8342 is as below:
>      <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
>                  or:origin="or:intended">
>        <interface or:origin="or:system">
>          <name>lo0</name>
>          <ip-address>127.0.0.1</ip-address>
>          <ip-address>::1</ip-address>
>        </interface>
>      </interfaces>
> 
> ?  Here keys are originated from "system", but it is under container of "intended". So if user gives "system" for "origin-filter", the output will still NOT have this instance output ?

We allow origin values on containers or lists in order to inherit them, i.e., to achieve a more compact encoding. Anyway, if a leaf node matches, then I think any encompassing containers and list should be included in the result so that the matching leaf can be reported. So you would return

      <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
                  or:origin="or:intended">
        <interface or:origin="or:system">
          <name>lo0</name>
          <ip-address>127.0.0.1</ip-address>
          <ip-address>::1</ip-address>
        </interface>
      </interfaces>

instead of not returning anything at all.

> ?  Also the container is not defined as "presence" in C.3.  Interface Example, but still it has origin whether that is Ok ?

Why not?
[Rohit R Ranade] RFC 8342 Section 5.3.4
" The origin applies to all configuration nodes except non-presence containers.  "

/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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 May 2018 14:54:53 +0200

> [Rohit R Ranade] While this looks OK for the origin filter, for the negated-origin-filter, for the same example given above, if <negated-origin-filter> or:intended<negated-origin-filter> is given,…

I think the leafs matter. Origin values on container and list nodes
are used for compactness. I think I wrote this already.

>    Can you please clarify whether the negated filter has higher priority than the selected filter ?

There are no priorities.

> " The origin applies to all configuration nodes except non-presence containers.  "

There are origin attributes that apply to the data node where the
attribute is present and there are origin attributes that exist in
order to inherit them to other data nodes. A node that is not carrying
a configuration value and is not a presence container may have an
origin attribute for inheritance purposes.

/js