Re: notification charter proposal

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:

> hi
>
> The only interest I saw historically in informs were from people who
> were disappointed we didn't run over TCP. After some investigation,
> people generally chose other means to maintain confidence that they were
> not loosing information.  I just didn't see informs used in practice. 
>
> Given we now run over TCP, I have difficulty seeing people using
> acknowledged notifications in practice. The solution could be defined,
> but I don't really know if there a lot of value in doing so.
>
>  

This is what I was trying to say (kind of).
We could define a mechanism so robust, it would be a reverse-RPC.
But what's good for serialized work-flow oriented data transfer
isn't so good for exception-based "get rid of it and get back to work"
kind of things.  

IMO, a transport-level ACK that the bytes got through is the most
we would need, and unless we change transports, this is what TCP
gives you whether you want it or not.

> Sharon
>  

Andy

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] 
> Sent: Tuesday, November 22, 2005 9:32 AM
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: Chisholm, Sharon [CAR:5K50:EXCH]; netconf@ops.ietf.org
> Subject: Re: notification charter proposal
>
>
> On Tue, Nov 22, 2005 at 09:00:20AM -0500, Glenn Waters wrote:
>
>  
>
> > > b) The notification sender sends a notification and gets a
> > >      
> confirmation
>  
>
> > >   that the notification was understood to the extend that it could
> > >      
> be
>  
>
> > >   handed over to an entity dealing with notifications. (This is
> > >      
> what
>  
>
> > >   SNMP notifications actually do.)
> > >      
> > I don't think that there is enough value in sending a response in this
> >    
>
>  
>
> > case since there is little recourse the sender can take to correct the
> >    
>
>  
>
> > issue. There is the possibility the sender could reduce the message 
> > size but that can be handled in other ways (such as the receiver 
> > reconfiguring the max size the sender should send). I can't think of 
> > what else a sender would possibly do with a response. Maybe it would 
> > help to identify those items to help decide if a response would be 
> > useful.
> >    
>
> Knowledge of the fact that you were not understood can be very useful,
> even if you do not know how to make yourself understood.
>
> You are arguing from a very narrow protocol centric perspective and 
> I agree that from this protocol centric perspective there is hardly
> something you can do. However, if you take a more system wide
> perspective, then I think one can easily make a case for b) and even for
> c).
>
> Note: I am not against a) nor am I against b) and c) - it is just
> important for me that once we talk about adding notifications, we better
> be clear what their semantics are and which role they can play in a
> systems view.
>
> /js
>
> PS: There are also strong ties here to notification logging (see the
>    NOTIFICATION-LOG-MIB produced by the DISMAN WG). The information
>    whether a notification was "understood" can actually be used to
>    decide what remains in a log and what can be purged. Without such
>    information, the notification originator actually has to log 
>    everything (and maybe rely on the receiver to clear log entries).
>
>  


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