[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: roots wasRe: filtering problem

Vincent Cridlig (vcridlig) wrote:

I also think one root including mounted subtrees for various namespaces
is better than concatenated multiple roots. These multiple roots can
become children of a main root in any case.
Otherwise filters will have to apply to many roots, rather than one. How
do you build the reply in case nodes from various roots are selected...?
This can happen when namespaces are reused in various data models to
include data following a generic structure.



Think about what this means.
Let's say there is a top-level element everybody is forced
to use, called <top>, in the NETCONF base namespace.
Every vendor would need to change every agent and every
manager to support this change.  NETCONF is supposed
to be content-independent.  This doesn't seem so independent.

All vendor and even all IETF data model objects are
going to be in different namespaces, so the child nodes of <top>
are all the nodes that would have appeared in <config> or <filter>,
accept moved down one extra XML layer.  It doesn't change the filtering
mechanism at all.  (This is the XML equivalent of the Spinal Tap
moment - "But this amp goes to 11").

The real problem that exists (if any), is the lack of a consistent
XML container for <copy-config> output.  I use the <config> element
in the NETCONF base namespace for this purpose.  It doesn't matter
so much what the QName value is for this top-level container,
but there does need to be one.  It ensures the <copy-config> output
will be valid XML, even if multiple data models from vendors
and the IETF exist in the agent.


In Xpath, one missing thing IMO is how is built the reply after an Xpath
get-request. Xpath result is always a node set. Is the reply a
concatenation of the result nodes, or is it a reconstructed document
containing the selected nodes? I don't think this is a data model
dependant question. This aspect is defined in the case of subtree
filtering and it should be defined also for Xpath.

Regards,
Vincent


Andy




-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of David B Harrington
Sent: vendredi 20 juillet 2007 7:20
To: 'Balazs Lengyel'; 'tom.petch'
Cc: ietf@andybierman.com; netconf@ops.ietf.org
Subject: RE: roots wasRe: filtering problem

I think we need one root, so a get-config will be able to include
everything.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net



-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel
Sent: Thursday, July 19, 2007 11:14 AM
To: tom.petch
Cc: ietf@andybierman.com; netconf@ops.ietf.org
Subject: Re: roots wasRe: filtering problem

Hello,
I think the datastore will often have multiple roots. I foresee/have heard of the following situations that as I understand are all valid in Netconf: 1) One root in one namespace, other namespaces might be mounted as subtrees 
2) One root per namespace
3) One namespace but with many root elements
4) Many roots in many namespaces
Case 2 can be viewed as a the single rooted case 1) where the first branching is according to the namespace.
Case 3) and 4) I feel the filter should be applied to each root and the results of these combined under the <data> element in the get/get-config reply. 

Comments?

Balazs

tom.petch wrote:

This may relate to something that has been bugging me.

XPath is - at times - specified in terms of a root, and an

XML document has a

single root element.  What is on the wire is an XML

document but the datastore

is not - as Andy has pointed out before.

So what is an XPath filter being applied to?  The event as

it would appear on

the wire as an XML document?  A conceptual document created

in the datastore for

the purposes of filtering?  And if the latter, should we -

we should! - specify

a root, either for the purposes of the examples or else for

everything.

RFC4741 is quite discursive about roots but the

notification I-D is silent; I

think that this last needs to change.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" <mbj@tail-f.com>
To: <ietf@andybierman.com>
Cc: <netconf@ops.ietf.org>
Sent: Friday, July 13, 2007 4:43 PM
Subject: Re: filtering problem



Andy Bierman <ietf@andybierman.com> wrote:

Hi,

There is another problem with filtering and the examples

in sec 5: (!!!)
The draft must say exactly where in the <notification> element that the <filter> is applied. The current text does not 
say anything.

Agreed.


All the examples in sec. 5 are broken because the

'notification type'

layer is missing.
I think it is ok. Specify that the filter is applied to the 'notificationContent' element as root (which is the 
abstract element).
The examples assume the filters can only be applied to a conceptual datastore, just like the <rpc> filter.
However, the most commonly needed filter is going to be on the notification type itself! 

Example (w/o namespaces):

   <notification>
     <configChange>
        <configChangeTime>date-time string...</configChangeTime>
        <configChangedBy>fred@example.com</configChangedBy>

<configTarget>/interfaces/interface[name='eth0']</configTarget>

         ...
     </configChange>
   </notification>
For simplicity, assume the manager just wants this one notification type. The filter is going to be 
something like:

  <filter type="subtree">
    <configChange/>
  </filter>

Yes, and IMO this is consistent with the examples.


/martin




A filter for configChange just on a specific configTarget

might be:

  <filter type="subtree">
    <configChange>

<configTarget>/interfaces/interface[name='eth0']</configTarget>

    </configChange>
  </filter>
The way the draft is now does not reflect how notifications are actually structured. 


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


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


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


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





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

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





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