Hi, Amar Jadagoud <ammys....@gmail.com> wrote: > Hi martin, > > Yes. I got your point. But what should be the parent record annotation > value? Whether it should be intended or origin annotation itself should not > exist?
I'm not sure I understand your question, but if the "with-origin" parameter is present in the request, the reply will contain "origin" annotations on all nodes (including ancestors) that have it. This handling is separate from any filters included. So even if you filter for "system" you might get nodes in the ancestor hierarchy with origin "intended", if you provided "with-origin". /martin > > Thanks, > Amar > > On Wed 30 Jan, 2019, 2:25 PM Martin Bjorklund <m...@tail-f.com wrote: > > > Hi, > > > > Amar Jadagoud <ammys....@gmail.com> wrote: > > > Hi, > > > > > > I have one doubt regarding origin-filter filtering in case of > > parent-child > > > hierarchy. > > > > > > If child class instance fields match with origin-filter value but parent > > > class instance fields does not, then what should be the rpc-reply > > content? > > > Does it need to include parent class instance record with only key fields > > > along with child class record or it should not include both parent and > > > child class instance record? > > > > This is not special for origin-filter, but applies to all filters. > > The description of get-data says: > > > > Any ancestor nodes (including list keys) of nodes selected by > > the filters are included in the response. > > > > Hope this answers your question. > > > > > > /martin > > > > > > > > > > Consider example given in 3.1.1.4 section of > > > draft-ietf-netconf-nmda-netconf-08 : > > > > > > <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> > > > > > > In the above example, user has provided origin-filter as system and > > > intended in the RPC request. So rpc-reply has both parent record with > > > "intended" origin and child record with "system" origin. > > > > > > What if user has provided only origin-filter="system" ? Do we need to > > > provide parent record with "intended" origin in the rpc-reply or should > > not > > > provide both parent and child record ? > > > > > > Thanks, > > > Amar > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
