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

Re: Pre-release 2 of Notification Update

Sharon Chisholm 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?


This needs to be clarified in the draft.
The filtering applies to the conceptual event messages,
not anything in the <running> configuration database.

NETCONF filtering applies to the content layer.
Since we want to be as consistent with <get> and <get-config>
filtering as possible, this is really the abstract 'notificationContent'
element.  The top-level <notification> element is a protocol-specific wrapper.
If this wrapper ever changes (e.g., SOAP) then the filters should
still work.




Sharon


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