Re: Informal Issue summary for Netconf Notification

[Andy Bierman <ietf@andybierman.com>]

Phil Shafer wrote:
> Balazs Lengyel writes:
>   
> > I think some guidelines about this question should be included in the notifications draft 
> > so people understand the situation the possibilities and the consequences.
> >     
>
> I just keep thinking about the times I need notifications while I'm
> doing a non-instantaneous RPC, such as <commit-config>.  Having to
> wait til the operation is done to see that my new igp config melted
> my network might be a bad thing.
>   

One big concern I have with the Notification draft is whether the 
inherent complexity
is warranted for the specific task at hand.   The first thing I notice 
is that there
aren't any deployed solutions which send notifications and operations on the
same connection. 

I find very little established operational validity in the idea that 
this is even
a "nice to have" feature, let alone mandatory functionality.
The cost of an additional connection for notifications is trivial.
The notion that this "shared session" mechanism somehow obviates the 
need to do
event correlation is also flawed.   A well-designed manager needs
to account for notifications that its own direct actions did not cause
(e.g., the notion that of all the notifications that get generated after 
a <commit> are
related to that <commit> may be  incorrect).


Andy


> Thanks,
>  Phil
>
> --
> 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/>