Re: Pre-release 2 of Notification Update

[Martin Bjorklund <mbj@tail-f.com>]

"Sharon Chisholm" <schishol@nortel.com> wrote:
> <andy>
> Given a conceptual notification message:
> 
>    <notification>
>     <fooEvent>
>       <eventClass>fault</eventClass>
>       <eventSeverity>major</eventSeverity>
>       <fooParam>ws1/hd0</fooParam>
>     </fooEvent>
>    </notification>
> 
> Do you want to force the string "/notification" to appear over and over
> in every filter, or start the filter at <fooEvent> instead, and save 13
> chars in almost every term in the expression?
> </andy>
> 
> Historically, optimizations that make thing less intuitive to save a few
> bits on the wire are not worth it (not being able to varbind in table
> indices into SNMP notifications, for example.)
> 
> I guess I had always thought the filter started at fooEvent because it
> was against the definition of the notification, not what was on the
> wire. What was the reasoning again to go with what is on the wire?

I think everyone agrees (or can live with) that the filtering starts
at the notificationContent element, i.e. in this case fooEvent.


/martin

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