retrieval filtering decision points

[Andy Bierman <abierman@cisco.com>]

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