Re: retrieval filtering decision points

[Andy Bierman <abierman@cisco.com>]

At 11:34 AM 6/10/2004, Juergen Schoenwaelder wrote:
>On Thu, Jun 10, 2004 at 10:42:41AM -0700, Andy Bierman wrote:
> 
>> The WG is deeply divided over subtree filtering vs. partial Xpath
>> for the solution to retrieval filtering for the <get-config> and
>> <get> operations.  The XML Directorate seemed to be divided as
>> well on the value of our Xpath subset or the potential harm of our
>> subtree filtering.  I am going to try to separate out the various
>> decision points, some of which appear to have WG consensus already.
>
>[...]
>
>Are you saying that the netconf protocol only supports an empty filter
>(which does not filter at all) and full xpath filtering becomes a 
>capability? I think this pretty much makes sense as a way out of this
>deadlock situation.

yes -- I'm saying the protocol should be independent of the
filter mechanism(s) used.  I am split myself on subtree vs.
Xpath subset.  Neither one is clearly better than the other,
and neither one comes close to full Xpath.


>Of course, it leaves it to the vendors and the market to decide where 
>the boundary between small and not so small devices is. And by saying 
>no filtering is the lowest bound common denominator, not so smart 
>applications will always do a full dump and filter on the manager side 
>to avoid dealing with different capabilities. (But something like that
>will happen whenever we have different filtering capabilities.)

Namespace filtering is some amount of filtering.
A vendor (or SDO) could purposely group management
information, just like we do with MIB modules.
This is much better than all or nothing, but not
good enough for bigger devices.

I don't think there is an optimal solution for all situations
possible here, so it's not a problem if multiple solutions
are pursued, or we migrate to better solutions when
they exist in the future.

 From the WG POV, we should push full Xpath 1.0, but allow for
other types of filtering as well.  If people are willing to
act as document editors, I think the WG should pursue either
new approach, with the understanding that the deliverable is
not coupled to NETCONF v1.0, in case the WG bogs down on
these other documents.


>What I do not yet understand is how namespaces play with this. I guess
>this needs more thought and investigation.

Either:

  <rpc message-id="101" xmlns="netconf-uri">
    <get>
      <data xmlns="http://example.com/schema-1"/>
    </get>
  </rpc>

or:

  <rpc message-id="101" xmlns="netconf-uri">
    <get>
      <data>
        <filter filter-type="namespace">
          http://example.com/schema-1
        </filter>
      </data>
    </get>
  </rpc>


>/js

Andy



>-- 
>Juergen Schoenwaelder               International University Bremen
><http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen, Germany 


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