Subject: [Netconf] Clarification about su tree filtering (Was: [netmod] Clarification about subtree filtering)

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 28 May 2018 08:30:46 -0400

Forwarding to NETCONF WG mailing list.

Begin forwarded message:

> From: Shiva Kumar Pathori <[email-masked]>
> Date: May 28, 2018 at 5:27:19 AM EDT
> To: Alex Campbell <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Clarification about subtree filtering
> 
> Thanks Alex for the clarification. Can somebody please clarify about subtree filter behaviour or provide some pointers in RFC so that I can refer to it.
> 
>> On Thu 24 May, 2018, 5:56 AM Alex Campbell, <[email-masked]> wrote:
>> Hi,
>> 
>> 
>> Since nobody else has answered I'll have a go.
>> I'm not familiar with subtree filtering, but I am with XPath. Assuming your XPath translation is accurate, it will return no data (response A).
>> 
>> From: netmod <[email-masked]> on behalf of Shiva Kumar Pathori <[email-masked]>
>> Sent: Tuesday, 22 May 2018 8:38 p.m.
>> To: [email-masked]
>> Subject: [netmod] Clarification about subtree filtering
>>  
>> 
>>> Hi,
>>> Can somebody clarify what could be the response for the <get-config> operation provided below.
>>> 
>>> Following is the user information in the datastore that is provided in the RFC 6241 as example.
>>>> <rpc message-id="101"
>>>>           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>        <get-config>
>>>>          <source>
>>>>            <running/>
>>>>          </source>
>>>>          <filter type="subtree">
>>>>            <top xmlns="http://example.com/schema/1.2/config">
>>>>              <users/>
>>>>            </top>
>>>>          </filter>
>>>>        </get-config>
>>>>      </rpc>
>>> 
>>>> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>   <data>
>>>>     <top xmlns="http://example.com/schema/1.2/config">
>>>>       <users>
>>>>         <user>
>>>>           <name>root</name>
>>>>           <type>superuser</type>
>>>>           <full-name>Charlie Root</full-name>
>>>>           <company-info>
>>>>             <dept>1</dept>
>>>>             <id>1</id>
>>>>           </company-info>
>>>>         </user>
>>>>         <user>
>>>>           <name>fred</name>
>>>>           <type>admin</type>
>>>>           <full-name>Fred Flintstone</full-name>
>>>>           <company-info>
>>>>             <dept>2</dept>
>>>>             <id>2</id>
>>>>           </company-info>
>>>>         </user>
>>>>         <user>
>>>>           <name>barney</name>
>>>>           <type>admin</type>
>>>>           <full-name>Barney Rubble</full-name>
>>>>           <company-info>
>>>>             <dept>2</dept>
>>>>             <id>3</id>
>>>>           </company-info>
>>>>         </user>
>>>>       </users>
>>>>     </top>
>>>>   </data>
>>>> </rpc-reply>
>>> 
>>> 
>>> The <get-config> operation with content-match at parent and child nodes;
>>> 
>>>> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>   <get-config>
>>>>     <source>
>>>>       <running/>
>>>>     </source>
>>>>     <filter type="subtree">
>>>>       <top xmlns="http://example.com/schema/1.2/config">
>>>>         <users>
>>>>           <user>
>>>>             <type>admin</name>
>>>>             <company-info>
>>>>               <dept>1</dept>
>>>>             </company-info>
>>>>           </user>
>>>>         </users>
>>>>       </top>
>>>>     </filter>
>>>>   </get-config>
>>>> </rpc>
>>> 
>>> The equivalent XPATH expression : 
>>>> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>   <get-config>
>>>>     <source>
>>>>       <running/>
>>>>     </source>
>>>>     <filter xmlns:t="http://example.com/schema/1.2/config" 
>>>>                  type="xpath"
>>>>                  select="/t:top/t:users/t:user[t:type='admin']/t:company-info[t:dept=’1’]"/>
>>>>         </get-config>
>>>>      </rpc>
>>> 
>>> For this what could be the response
>>> 
>>> a) The response based on content-match nodes are AND-ed together
>>>> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>        <data>
>>>>       </data>
>>>>      </rpc-reply>
>>> OR 
>>> 
>>> b)  The response based on content-match nodes treated separately
>>>> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>   <data>
>>>>     <top xmlns="http://example.com/schema/1.2/config">
>>>>       <users>
>>>>         <user>
>>>>           <name>fred</name>
>>>>           <type>admin</type>
>>>>           <full-name>Fred Flintstone</full-name>
>>>>         </user>
>>>>         <user>
>>>>           <name>barney</name>
>>>>           <type>admin</type>
>>>>           <full-name>Barney Rubble</full-name>
>>>>         </user>
>>>>       </users>
>>>>     </top>
>>>>   </data>
>>>> </rpc-reply>
>>> 
>>> 
>>> Regards,
>>> Shiva
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 May 2018 15:37:48 +0200 (CEST)

Hi,

See answers inline.

> >>>>                  select="/t:top/t:users/t:user[t:type='admin']/t:company-info[t:dept=’1’]"/>

This is not an equivalent expression, b/c a content-match node ("type")
is not AND:ed with a selection node ("company-info").

> >>>>           <full-name>Barney Rubble</full-name>

Sibling content-match nodes are AND:ed, but in this case "type" and
"dept" are not siblings.

The correct reply is:

   <data>
           <name>fred</name> (*)
           <type>admin</type>
         </user>
         <user>
           <name>barney</name> (*)
           <type>admin</type>
         </user>
       </users>
     </top>
   </data>

(*) note that if the name is the key, it MAY (or may not) be present
in the output, see 6.2.5 of RFC 6241:

   o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

/martin