So do you mean that origin-filter needs to be applied on the response data but origin annotation should not be provided in the rpc-reply?
On Wed 30 Jan, 2019, 4:05 PM Martin Bjorklund <[email protected] wrote: > Amar Jadagoud <[email protected]> wrote: > > 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. > > Yes, this is intentional. "with-origin" is orthogonal from any > filters. > > > So we consider it as with-origin scenario and provide > > origin annotation in parent and child record. > > If the client didn't pass the "with-origin" parameter, the server > should not fill in the "origin" annotations, even if "origin-filter" > was passed. > > > /martin > > > > Does below point holds true > > for this case too? > > > > > > > Thanks, > > Amar > > > > On Wed 30 Jan, 2019, 3:24 PM Martin Bjorklund <[email protected] wrote: > > > > > Hi, > > > > > > Amar Jadagoud <[email protected]> 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 <[email protected] wrote: > > > > > > > > > Hi, > > > > > > > > > > Amar Jadagoud <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
