Subject: RE: notification charter proposal

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 24 Nov 2005 10:23:04 -0500

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.

Sharon

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, November 22, 2005 9:32 AM
To: Waters, Glenn [CAR:IO47:EXCH]
Cc: Chisholm, Sharon [CAR:5K50:EXCH]; [email-masked]
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).

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Nov 2005 08:34:28 -0800

>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