Re: Proposed Update to Netconf Charter

[Vincent Cridlig <vincent.cridlig@loria.fr>]

Hi,

The tests made on our Netconf implementation shown us that XPath 
filtering is as fast as subtree filtering except
in the following situation: a XPath expression that is not an absolute 
path like '//user'

In that case, it is hard to predict what part of the data model is 
concerned. Two solutions were possible for us:
- parse the XML Schemas from our database and try to find the ones which 
have a "user" element
- build the whole configuration document and apply the XPath expression 
on it

The first approach is difficult to perform and suppose that all data 
models are defined with XML Schema (not DTD or other).
The second approach is time consuming.

We chose the second one since it's easier in our environment even if not 
satisfying.

To improve this, what I suggest is to modify XPath filtering a little bit.
Most programming languages allow to define a namespace context before 
applying an XPath expression to a document.
It would be nice to allow namespaces contexts definition in the Netconf 
requests:

<filter type="xpath">
   <expression>//net:network/if:interfaces/if:iface/if:name</expression>
   <ns-contexts>
       <ns-context>
           <ns-short>net</ns-short>
           <ns-long>urn:network:data:model</ns-long>
       </ns-context>
      <ns-context>
           <ns-short>if</ns-short>
           <ns-long>urn:network:interfaces:data:model</ns-long>
       </ns-context>
   </ns-contexts>
</filter>

Currently, a way to do something equivalent is the following:
<filter type="xpath">
//*[namespace-uri()='urn:network:data:model' and 
local-name()='network']/*[namespace-uri()='urn:network:interfaces:data:model' 
and 
local-name()=interfaces]/*[namespace-uri()='urn:network:interfaces:data:model' 
and 
local-name()='iface'/*[namespace-uri()='urn:network:interfaces:data:model' 
and local-name()='name']
</filter>

While the first one is easy to read and write for a human, the second is 
more difficult.

In both cases, it allows to bind easily the XPath expression to the 
right part of the data model.

I think the problem is similar in the case of access control which is 
somewhat the same process as XPath or subtree filtering (in the case of 
a read operation). To illustrate this, our implementation expresses the 
access control policy with XPath and uses the same methods to filter the 
document for access control or filtering operations.

Vincent CRIDLIG


Juergen Schoenwaelder wrote:

> On Tue, Jul 05, 2005 at 03:14:52PM -0700, Andy Bierman wrote:
>
>  
>
> > 3) tier 2 is data model access, and defined by the tuple:
> >
> > { operation-list, data-namespace, data-path, group-list }
> >
> > where:
> >
> > operation-list is zero or more of the following strings:
> >    { notify, read, create, merge, replace, delete }
> >    [Shorthand: the term 'write' == create, merge, replace, delete]
> > data-namespace is the URI identifying the data model namespace
> > data-path is an absolute XPATH expression identifying the
> >    top-level data model node that this access applies
> > group-list is a list of group names granted access
> >    
>
> While all this sounds reasonable, I am really surprised that you
> propose XPATH expressions given the lengthy discussion in the past
> that XPATH expressions are too expensive for filtering. Or is it
> because you expect access control on the 2nd tier not to be
> mandatory to implement and an optional feature like XPATH 
> filtering?
>
> Sorry, I could not resist to ask this question. But despite this
> somewhat polemic question, I do like the 2 tier approach that you
> have outlined.
>
> /js
>
>  


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