On Wed, May 02, 2018 at 11:28:42AM +0000, Rohit R Ranade wrote: > Hi Juergen, > > Some thoughts in-lined. > > With Regards, > Rohit R Ranade > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:[email protected]] > Sent: 25 April 2018 16:12 > To: Rohit R Ranade <[email protected]> > Cc: [email protected]; [email protected] > 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.
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. > > 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. " > 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 -- 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
