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

From: Amar Jadagoud <[email-masked]>
Date: Wed, 30 Jan 2019 12:34:16 +0530

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?

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jan 2019 09:55:58 +0100 (CET)

Hi,

> 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

---

From: Amar Jadagoud <[email-masked]>
Date: Wed, 30 Jan 2019 15:16:33 +0530

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?

Thanks,
Amar

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jan 2019 10:54:54 +0100 (CET)

Hi,

> value? Whether it should be intended or origin annotation itself should not

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jan 2019 11:12:59 +0100

> value? Whether it should be intended or origin annotation itself should not

The origin annotation on a non-presence container has no meaning other
than providing a default that is inherited downwards. In general,
multiple representations are possible that all have the same meaning
(but may take different amounts of space on the wire).

/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/>

---

From: Amar Jadagoud <[email-masked]>
Date: Wed, 30 Jan 2019 15:56:12 +0530

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 <[email-masked] wrote:

> > > > provide parent record with "intended" origin in the rpc-reply or
> should
> > > not

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jan 2019 11:35:56 +0100 (CET)

Amar Jadagoud <[email-masked]> wrote:
> 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?

---

From: Amar Jadagoud <[email-masked]>
Date: Wed, 30 Jan 2019 16:16:02 +0530

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-masked] wrote:

> > > > value? Whether it should be intended or origin annotation itself
> should
> > > not
> > > > exist?
> > >
> > > > > > 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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jan 2019 11:49:01 +0100 (CET)

> but origin annotation should not be provided in the rpc-reply?

Yes.  The filters is a set of mechanisms to reduce the result to match
certain criteria.  "with-origin" (and "with-defaults") are separate
mechanisms to tag the resulting nodes with meta data.

/martin