Re: [Netconf] Clarification about subtree filter

[Martin Bjorklund <[e-mail]>]

Hi,

Shiva Kumar Pathori <[e-mail]> wrote:
> Hi,  Sorry did not update subject line, It's updated now.
> 
> On Wed 30 May, 2018, 2:53 AM , <[e-mail]> wrote:
> 
> > Send Netconf mailing list submissions to
> >         [e-mail]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >         https://www.ietf.org/mailman/listinfo/netconf
> > or, via email, send a message with subject or body 'help' to
> >         [e-mail]
> >
> > You can reach the person managing the list at
> >         [e-mail]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Netconf digest..."
> >
> >
> > Today's Topics:
> >
> >    1. Re: Netconf Digest, Vol 123, Issue 43 (Shiva Kumar Pathori)
> >    2. How would RESTCONF access multiple datastores defined by NMDA
> >       (Henry Yu)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Wed, 30 May 2018 01:29:53 +0530
> > From: Shiva Kumar Pathori <[e-mail]>
> > To: [e-mail]
> > Subject: Re: [Netconf] Clarification about subtree filter
> > Message-ID:
> >         <
> > [e-mail]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> > What could be the reason for not including the "<full-name>" leaf in the
> > reply?
> > I see the example in section 6.4.5 in RFC 6241 include the above mentioned
> > leaf when a content match node present in the filter.

The reason is that in your example, there is a selection node
("company-info") which means that data from that node only is included
in the reply.  In 6.4.5 there is no selection node, which means that
all sibling nodes are selected.  Compare with the example in 6.4.6.


/martin


> >
> > BTW, the reply is same for the both xpath and subtree filter RPCs mentioned
> > in the mail?
> >
> > On 29 May 2018 at 00:30, <[e-mail]> wrote:
> >
> > > Send Netconf mailing list submissions to
> > >         [e-mail]
> > >
> > > To subscribe or unsubscribe via the World Wide Web, visit
> > >         https://www.ietf.org/mailman/listinfo/netconf
> > > or, via email, send a message with subject or body 'help' to
> > >         [e-mail]
> > >
> > > You can reach the person managing the list at
> > >         [e-mail]
> > >
> > > When replying, please edit your Subject line so it is more specific
> > > than "Re: Contents of Netconf digest..."
> > >
> > >
> > > Today's Topics:
> > >
> > >    1. Re: Clarification about su tree filtering (Martin Bjorklund)Hi
> > >
> > >
> > > ----------------------------------------------------------------------
> > >
> > > Message: 1
> > > Date: Mon, 28 May 2018 15:37:48 +0200 (CEST)
> > > From: Martin Bjorklund <[e-mail]>
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [Netconf] Clarification about su tree filtering
> > > Message-ID: <[e-mail]>
> > > Content-Type: Text/Plain; charset=utf-8
> > >
> > > 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
> > >
> > > ------------------------------
> > >
> > > Subject: Digest Footer
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> > >
> > > ------------------------------
> > >
> > > End of Netconf Digest, Vol 123, Issue 43
> > > ****************************************
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > https://mailarchive.ietf.org/arch/browse/netconf/attachments/20180530/93583caa/attachment.html
> > >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 29 May 2018 17:23:07 -0400
> > From: Henry Yu <[e-mail]>
> > To: [e-mail]
> > Subject: [Netconf] How would RESTCONF access multiple datastores
> >         defined by NMDA
> > Message-ID:
> >         <
> > [e-mail]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > According to my understanding of RFC 8040, there is only one datastore
> > (which is represented by "{+restconf}/data"). But NMDA introduces multiple
> > datastores. How does RESTCONF provide access to them? I think a RESTCONF
> > user would, at minimum, need the access to the <running> and the
> > <operational>.
> >
> > Thanks,
> > Henry
> > P.S., I would not find an answer in the mailing list's archive. My
> > apologies if this question has already been asked/answered.
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> > https://mailarchive.ietf.org/arch/browse/netconf/attachments/20180529/81c594a0/attachment.html
> > >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > Netconf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> >
> > ------------------------------
> >
> > End of Netconf Digest, Vol 123, Issue 44
> > ****************************************
> >