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

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