[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: roots wasRe: filtering problem
David B Harrington wrote:
Hi,
SNMPv3 provides two types of filtering of notifications:
1) access control (where the "filters" are defined by the admin), and
2) customized filtering (where the user filters out uninteresting
data)
Do I understand correctly that you are proposing adding the second
type of filtering to netconf notifications?
NETCONF has always have several custom filtering mechanisms,
and vendors are adding more all the time (e.g., with-defaults).
Whatever makes it easiest on the operator will most likely get done.
The filtering in Notifications is different for 2 reasons,
as Martin has described in hallway BoFs...
1) the filter applies to the notification message, not the conceptual
NETCONF configuration database, so the agent code may need significant
modification to support notification filtering.
If the agent supports the #xpath capability and the #notification
capability, then it must support xpath filtering of notifications.
(This is what the current draft implies.)
2) Instead of pruning data, like for <get> responses, the notification
filter returns true or false, and determines whether the entire
filter is dropped or not on a particular session.
Where does one find severity in a netconf notification? Is that part
of the netconf data model, i.e. part of the netconf stream?
It is part of a data model for the notification content,
written by some vendor or SDO.
The WG did not reach agreement on a generic (same say reinvented)
event classification system.
More standards work is needed on the structure of content in
the NETCONF stream. (People will submit proposals I think ;-)
IIRC, in Montreal we talked about filters being specific to the stream
type, so a syslog stream might be filtered on severity and facility
(or priority), but it would be hard to filter an SNMP stream on those
properties. Are you proposing some type of netconf-specific classes
for filtering on these types of properties? How would you map to these
for the SNMP stream?
This would be a new kind of filtering.
We are trying to reuse the existing mechanisms as much as possible.
Access control on a stream? Filter on a stream?
IMO, this is not relevant to the NETCONF protocol.
NETCONF says that the filters work on XML, not conceptual streams.
That can only mean the individual notification elements which
contain an eventType from a particular namespace. There is no
restriction that the same QName could not be used in a different
stream (especially combo-streams). So it may seem like a nit,
but let's try to keep the XML stuff straight.
For our purposes, the agent must construct (at least conceptually)
an XML instance document to compare against the filter, and
interpret the output and process it according to what RFC 4741 or the
Notification draft expects to happen.
David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
Andy
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel
Sent: Monday, July 30, 2007 12:33 PM
To: Andy Bierman
Cc: tom.petch; netconf@ops.ietf.org
Subject: Re: roots wasRe: filtering problem
Hello,
I think a filter that works on the content of the
notification (as it would be sent) is needed.
People usually filter on things like severity or eventType.
E.g. severity is not even part of
the data model.
I think the filter should work on the notification content.
Balazs
Andy Bierman wrote:
tom.petch wrote:
----- Original Message -----
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
To: "tom.petch" <cfinss@dial.pipex.com>
Cc: <ietf@andybierman.com>; <netconf@ops.ietf.org>
Sent: Thursday, July 19, 2007 5:14 PM
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?
Mmmm - even more complex than I thought. My initial concern was
whether or not
the Notifications, the draft in Last Call, were regarded
for filtering
purposes
as part of the configuration datastore at all, or whether
the filter
was applied
to the document as it would appear on the wire were it to
pass a filter.
This is the $64 question.
When a <filter> element is provided in the <create-subscription>,
does it apply to the conceptual (internal) NETCONF database,
or rather an XML instance document representing the database?
(no)
The examples seem to contradict text that says it works like
<get>.
They show the filter is for the <notification> contents,
starting at its one and only child node -- e.g., <event>.
The draft needs to specify the data root for the
notification <filter>.
Tom Petch
Balazs
Andy
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/>
--
Balazs Lengyel Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320 Fax: +36 1 4377792
Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com
--
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/>