[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: notification charter proposal

NETCONF over SOAP is a candidate which would need Notification
acknowledgement.
Since SOAP can be implemented over UDP too.

Notifications acknowledgement for parallel notifications can be costly to
implement in some devices with limited memory.

Should we have notifications-acknowledgement as a capability?

regards
Jayaprakash
Wipro Technologies

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Sharon Chisholm
Sent: Thursday, November 24, 2005 6:19 PM
To: netconf@ops.ietf.org
Subject: RE: notification charter proposal

hi

No, they are not the same, but the transport layer one seems to be
sufficient from what I have seen. I suggest we don't do anything to
preclude the later addition of an application level acknowledgements,
but that we don't provide one now. The design in the current draft does
this.

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of McDonald, Ira
Sent: Thursday, November 24, 2005 3:58 PM
To: netconf@ops.ietf.org
Subject: 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/>


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


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