[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 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/>