Re: Notification Message Processing Model

[Steve Berl <sberl@cisco.com>]

The main use that I see for notifications is for "configuration change
notifications". A netconf based client would like to know if someone else is
changing the configuration, and just what it is that has been changed. The
notification needs to include information about who made the change, when
they made the change, and exactly what they changed. Just a dumb
notification that "something changed" is not good enough. We need to send a
potentially large message describing the actual changes made. This data is
typically too large to send over a standard syslog message or SNMP trap.

-steve


On 3/24/06 7:19 AM, "Balazs Lengyel" <balazs.lengyel@ericsson.com> wrote:

> Hello,
> We definitely want to use notifications for alarms (something that the
> operator must 
> handle), events (something that the operator should notice) besides log
> messages.
> 
> A never ending rpc-reply just seems strange/ugly to me. Having an XML element
> that might 
> have infinite size is something I don't like.
> I feel that using a never ending rpc-reply is a much bigger deviation from the
> original 
> rpc usage then
> - just saying that we don't wrap notifications in an rpc or
> - using one-way message wrappers instead of the rpc
> 
> Balazs
> 
> 
> 
> Andy Bierman wrote:
>> Phil Shafer wrote:
>>> Shane Kerr writes:
>>>> Each notification is valid XML, self contained. Do we really need to
>>>> wrap the set for some reason?
>>> 
>>> I see the other side.  Do we really need to break the existing RPC
>>> mechanism for something that can be easily handled within it?  Given
>>> that the notifications are likely to get simple syslog messages,
>>> the requirement to be self contained is easily fulfilled.
>> 
>> I believe the kind of tool that only does stand-alone full
>> document parsing should not be the focus of our design.
>> This seems to be like designing SNMP for MIB walker tools.
>> When that happened, it became almost all SNMP was good for.
>> 
>> I suspect that all the actual agent and manager implementers
>> will be using an event-driven parser, not a document-driven parser.
>> 
>> Since the WG doesn't agree on the functional requirements
>> for notifications, it is not surprising that there is no
>> agreement on the solution.  Since all Phil and I really want to do
>> with NETCONF notifications is deliver text or XML syslog,
>> this would be fine.  I'm not sure what the rest of the WG
>> wants to do with these things.
>> 
>> I hate Requirements Documents but this document has hardly
>> been read or reviewed by anybody in the WG.  I think we
>> should try to agree on what we want to do with NETCONF
>> notifications before going any further.  Real use cases,
>> based on real products, used in real networks -- not
>> "nice-to-have", "maybe need this someday" features.
>> 
>> 
>>> 
>>> Thanks,
>>>  Phil
>> 
>> 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/>