subtree filter spec vs. implementation

[Andy Bierman <ietf@andybierman.com>]

Hi,

Does the Juniper implementation of subtree filtering work
as literally defined in the spec, or more as a boolean filter?

In our usual example, let's say the <users> container exists,
and the user issues a get-config command:

----------------------------------------------------------------------------

 <rpc message-id="101" xmlns="netconf-blah">
   <get-config>
     <source><running/></source>
     <filter type="subtree">
       <top xmlns="example.com-blah">
         <users>
           <user>
             <name>fred</name>
           </user>
         </users>
       </top>
     </filter>
   </get-config>
 </rpc>


According to the spec (as Martin and I understand it)
there are 3 possible outcomes here (assuming read access is granted):

1) If <users> is empty:

 <rpc-reply message-id="101" xmlns="netconf-blah">
   <data>
     <top xmlns="example.com-blah">
       <users/>
     </top>
   </data>
 </rpc-reply>

2) If <users> is not empty, but entry for 'fred' does not exist:

 <rpc-reply message-id="101" xmlns="netconf-blah">
   <data>
     <top xmlns="example.com-blah">
       <users>
         <user/>
       </users>
     </top>
   </data>
 </rpc-reply>

3) Entry for 'fred' exists

 <rpc-reply message-id="101" xmlns="netconf-blah">
   <data>
     <top xmlns="example.com-blah">
       <users>
         <user>
           <name>fred</name>
           <type>admin</type>
         </user>
       </users>
     </top>
   </data>
 </rpc-reply>

-------------------------------------------------------------------------

So is this how Juniper (and others) are implementing subtree filtering?
If so, it is clearly useless for notification content filtering.
But there is minor operational value in knowing (1) or (2) vs.
knowing (3) or nothing.  IMO, not enough to justify implementing
subtree filtering this way though.

For cases (1) and (2) I believe the XMLCONF design team envisioned
this response:

 <rpc-reply message-id="101" xmlns="netconf-blah">
   <data/>
 </rpc-reply>

However, this response is incorrect according to the spec.
I would like to converge on the standard behavior of details
like this ASAP.

<soapbox>
I cannot over-stress how important it is from an NMS POV that
the netconf standard provide a CONSISTENT programming interface.
There must be a clear distinction between the "window to the native CLI"
concept and standard behavior. Subtree filtering needs to be 
inter-operable,
or it will be removed when the protocol is evaluated for
standards-track advancement.)
</soapbox>


thanks,
Andy



--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>