Subject: retrieval filtering decision points

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Jun 2004 10:42:41 -0700

Hi,

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.

D1) Applicability and scale

There seems to be consensus that not every device has the same
need for retrieval filtering, or the ability to support various SW
solutions.  Therefore, any mandatory-to-implement filtering
mechanism must take this into account.

Very small devices do not have large configurations, and the amount
of state data contained in a single namespace can be controlled by the 
vendor to a large degree.  It is therefore quite reasonable for this 
type of device not to need any further retrieval filtering at all.

Very large devices can have huge configurations and a huge amount
of state data as well.  Only full Xpath (of our choices) will
likely be suitable for this type of device.

There are 3 levels of retrieval filtering being considered for 
NETCONF devices:

   Level 1: namespace - specify the target namespace to retrieve
   Level 2: something other than full Xpath 1.0
   Level 3: Xpath 1.0

D2) Explicit vs. Implicit Filters

There is WG consensus that the <get-config> and <get> operations
should use a parameter called <filter> to identify the filter type
and hold the filter contents, instead of directly placing the
filter contents in the <config> or <state> parameters.
The <filter> mechanism allows the NETCONF protocol to easily support 
multiple retrieval mechanisms, and/or different versions of
retrieval mechanisms over time.

D3) Full Xpath support

The seems to be WG consensus that v1.0 should utilize full Xpath 1.0,
although there is not consensus that this should be mandatory for
all devices. 

  - A string (or perhaps URI) to identify Xpath as a supported NETCONF 
    filter type should be defined.  
  - The #xpath capability should be defined, which indicates that the
    agent supports full Xpath 1.0, and allows filter-type="<xpath-ID>" 
    (value TBD) in <get-config> and <get> operations.
  - The WG must decide if full Xpath support MAY or SHOULD be supported
    by every NETCONF agent.

D4) Decoupling the protocol document from the retrieval filtering
    mechanism(s)

There seems to be WG consensus that definition of any XML subtree 
filtering mechanisms is not a core task for the NETCONF WG, and 
not critical to protocol operation.   It does not appear that the
WG will reach consensus on which new filtering mechanism (subtree
or Xpath subset) to develop.  It is also not clear that agreement
on the exact features or details of either proposal will be easy
to achieve.

 - The WG must decide if all definition of XML filter mechanisms 
   should be removed from the protocol document.  
 - If so, the WG must also decide if either (or both) of the 
   filter proposals should be developed as RFCs, and their type 
   (Proposed Standard, Informational, Experimental).

thanks,
Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jun 2004 20:34:29 +0200

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

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

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

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Jun 2004 11:58:05 -0700

>capability? I think this pretty much makes sense as a way out of this

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.

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

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

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 10 Jun 2004 21:08:59 +0200

>           http://example.com/schema-1

I am not sure as long as I do not know the details how xpath works
together with namespaces. As I said, this needs more thoughts (at
least on my side).

/js

---

From: Frank Strauß <[email-masked]>
Date: Fri, 11 Jun 2004 00:17:52 +0200

> together with namespaces. As I said, this needs more thoughts (at

The native way to filter based on a namespace could simply be
achieved through XPath and look like this:

<?xml version="1.0"?>
<rpc xmlns="netconf-uri"
      xmlns:s1="http://example.com/schema-1"
      message-id="101">
   <get-config select="s1:*"/>
</rpc>