Subject: Re: notification charter proposal

From: "David T. Perkins" <[email-masked]>
Date: Thu, 12 Jan 2006 20:00:27 -0800 (PST)

HI,

Just to make sure that there is no possibility
of lost notifications...

Please correct me if I've got this incorrect.

I do believe that you can loose the last "n" notifications
that you have sent unless you do application level
acks. In this case, the notification receiver
should receive the notification, write it to stable
storage, and then provide the app level ack.
How many notifications can be lost depends
on the implementation of the app and the stack.

What do you think?

Regards,
/david t. perkins

On Wed, 23 Nov 2005, Eliot Lear wrote:

> Glenn Waters wrote:
> > Ahh, the challenges of multiple transports with differing features. So,
> > if we chose (b) then we don't *need* to do anything the protocol for
> > BEEP transport but we *need* to include something in the protocol for
> > SSH transport (and SOAP I just don't know).
> > 
> > Of course Netconf is transport independent so if we chose (b) then we
> > *must* include in acks in the proto which means the BEEP transport will
> > have an extra ack.
> 
> How about "The right tool for the right job?"  For those who need this
> sort of thing, use BEEP.
> 
> Eliot
> 
> --
> 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, 13 Jan 2006 08:49:38 +0100

It depends on how BEEP is treated.  If BEEP is treated as a TCP then
you're right.  If BEEP can allow for some amount of application control
(like "let me tell you when to ACK") then no.  BEEP: neither fish nor
fowl!  A feature.

Eliot