Re: [Netconf] Netconf Digest, Vol 123, Issue 43

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.

BTW, the reply is same for the both xpath and subtree filter RPCs mentioned
in the mail?

On 29 May 2018 at 00:30, <netconf-request@ietf.org> wrote:

> Send Netconf mailing list submissions to
>         netconf@ietf.org
>
> 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
>         netconf-request@ietf.org
>
> You can reach the person managing the list at
>         netconf-owner@ietf.org
>
> 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 <mbj@tail-f.com>
> To: mjethanandani@gmail.com
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] Clarification about su tree filtering
> Message-ID: <20180528.153748.2044064270808262081.mbj@tail-f.com>
> Content-Type: Text/Plain; charset=utf-8
>
> Hi,
>
> See answers inline.
>
>
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> > Forwarding to NETCONF WG mailing list.
> >
> > Begin forwarded message:
> >
> > > From: Shiva Kumar Pathori <pathori@gmail.com>
> > > Date: May 28, 2018 at 5:27:19 AM EDT
> > > To: Alex Campbell <Alex.Campbell@aviatnet.com>
> > > Cc: netmod@ietf.org
> > > 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, <
> Alex.Campbell@aviatnet.com> 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 <netmod-bounces@ietf.org> on behalf of Shiva Kumar
> Pathori <pathori@gmail.com>
> > >> Sent: Tuesday, 22 May 2018 8:38 p.m.
> > >> To: netmod@ietf.org
> > >> 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
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>
> ------------------------------
>
> End of Netconf Digest, Vol 123, Issue 43
> ****************************************
>