Re: [netmod] Regarding origin-filter in draft-ietf-netconf-nmda-netconf-08

[Amar Jadagoud <[e-mail]>]

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 <[e-mail] wrote:

> Hi,
>
> Amar Jadagoud <[e-mail]> 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 <[e-mail] wrote:
> >
> > > Hi,
> > >
> > > Amar Jadagoud <[e-mail]> 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
> > >
>