Hi Martin, Yes. I got your point. Thanks.
One more question : Libyang does not return error if origin-filter is provided in the rpc request without "with-origin" parameter as ietf-netconf-nmda module does not mandate it. So we consider it as with-origin scenario and provide origin annotation in parent and child record. Does below point holds true for this case too? Thanks, Amar On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund <m...@tail-f.com wrote: > 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
