Re: requirement: agent initiated session support

[Shane Kerr <shane@isc.org>]

On Monday 03 April 2006 17:17, Sharon Chisholm wrote:
> hi
>
> This is similar to the event replay work we have done. Our method
> works fine without persistent subscriptions. The user creates a new
> subscription with a timestamp that indicates the start of the
> replay window and the other parameters it sends when it creates a
> normal subscription.
>
> We didn't include it in the draft since we felt it could be done
> later as an optional capability.
>
> Is there interest in including replay in release one?

I had actually been considering the replay idea previously, although 
my take on it was surely different from yours. My thinking was that 
having replay would make the need for mixing command and notification 
channels. Here's the idea:

client -> subscribe for (a, b, c), begin anywhere
server <- event a, #121
server <- event c, #122
server <- event b, #123

At this point, the client wants to change the subscription because 
something interesting happened. So it can create a new channel, and:

client -> subscribe for (a, b, c, d), begin at 124
server <- event a, #124
   .
   .
   .

Of course, this isn't the only purpose for it. It would be useful at 
any time when a client lost connection for a while. Consider the case 
where the client (or server) lost an interface. If you could specify 
the event to start at, then you would be able to transparently live 
through disconnects.

Also, I don't have a problem with using a timestamp, although I think 
using a server-specified increasing number might make more sense. 
Otherwise a client will have to filter go back to the previous second 
and filter out duplicates, if there are multiple events per second.

--
Shane

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