Re: [Netconf] Clarification about su tree filtering

[Martin Bjorklund <[e-mail]>]

Hi,

See answers inline.


Mahesh Jethanandani <[e-mail]> wrote:
> Forwarding to NETCONF WG mailing list.
> 
> Begin forwarded message:
> 
> > From: Shiva Kumar Pathori <[e-mail]>
> > Date: May 28, 2018 at 5:27:19 AM EDT
> > To: Alex Campbell <[e-mail]>
> > Cc: [e-mail]
> > 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, <[e-mail]> 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 <[e-mail]> on behalf of Shiva Kumar Pathori <[e-mail]>
> >> Sent: Tuesday, 22 May 2018 8:38 p.m.
> >> To: [e-mail]
> >> 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>

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

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

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

The correct reply is:

   <data>
     <top xmlns="http://example.com/schema/1.2/config">
       <users>
         <user>
           <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