Subject: RE: notification charter proposal

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 24 Nov 2005 12:58:09 -0800

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: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Sharon Chisholm
> Sent: Thursday, November 24, 2005 10:23 AM
> To: [email-masked]
> 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:[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/>
> 

--
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: Eliot Lear <[email-masked]>
Date: Fri, 25 Nov 2005 09:15:40 +0100

> that indicates receipt of a well-formed XML message.

What is of particular concern is the way things are going in ISMS, where
because of the existing ASIs and elements of procedure a question came
up over how to signal back to the upper layers when a TCP connection has
failed.  One solution was to simply ignore the problem and let the upper
layer deal with the problem as if the transport WERE unreliable.  I
don't like that approach because it doesn't properly take advantage of
TCP's ability to alert the application to a network problem.

Related- we are currently in a bit of a scrum with ATIS TMOC over IPFIX
about application layer acknowledgments.  There they want 100%
reliability "from disk to disk".  That means that even a TCP ACK is not
sufficient because the recipient stack will have ACKed probably several
ms before that point.

Here is the question: what level of reliability is necessary for the
applications we have in mind?  The above example is for accounting where
arguably money is involved.  Are these notifications going to be used to
derive a revenue event (SLA management, for instance) such that if a
recipient crashes and the event is lost after having been acknowledged
somebody would be upset?

I don't envision that.  Therefore I wouldn't include it.  However, if
somebody wants it they can still have it by using BEEP.  All of this
having been said...

> behave the same over any transport.

If NETCONF is to behave the same over any transport then why have more
than one?  Why are we going through a last call for THREE transports?

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Nov 2005 09:32:11 -0800

>than one?  Why are we going through a last call for THREE transports?

This is irrelevant.
The <edit-config> operation does not behave differently over the 3 
transports.
All options to all operations are available, regardless of transport choice.
Make the same true for notifications or (IMO) this whole thing is dead 
on arrival.

>Eliot

Andy