[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: notification charter proposal
Hi,
As Juergen Schoenwaelder just pointed out - a transport layer
ACK does NOT have the same semantics as an upper layer ACK
that indicates receipt of a well-formed XML message.
Confusing the two is not helpful - NetConf is supposed to
behave the same over any transport.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Sharon Chisholm
> Sent: Thursday, November 24, 2005 10:23 AM
> To: netconf@ops.ietf.org
> Subject: RE: notification charter proposal
>
>
> 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: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).
>
> --
> 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/>
>
--
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/>