[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: roots wasRe: filtering problem
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?
Where does one find severity in a netconf notification? Is that part
of the netconf data model, i.e. part of the netconf stream?
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?
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: 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/>