Subject: RE: requirement: agent initiated session support

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 3 Apr 2006 11:17:23 -0400

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?

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, April 03, 2006 11:13 AM
To: Phil Shafer
Cc: Chisholm, Sharon [CAR:ZZ00:EXCH]; Netconf (E-mail)
Subject: Re: requirement: agent initiated session support

Phil Shafer wrote:
> Andy Bierman writes:
>> In the subscribe model, none of the agents can send any notifications

>> until a manager connects to them and asks for notifications.  The 
>> startup notifications are critical to have, to check for any 
>> config/image/HW mismatches that occurred during boot-up.
> 
> We do this with our accounting-profiles RPC (which I'm planning on 
> mimicing for syslog data) with a combination of the <realtime/> flag 
> and the <since>timestamp</since argument.  The system makes local 
> copies of accounting records and can serve them up with a starting 
> window, in realtime, or as a combination, where the records since the 
> given timestamp are passed along and then the RPC switches to 
> realtime.
> 
>   <rpc>  <!-- from memory; check docs for accurate details -->
>     <get-accounting-records>
>       <since>YYYY-MM-DD.HH:MM:SS</since>
>       <realtime/>
>     </get-accounting-records>
>   </rpc>

I like this!  (Reminds me of RMON TimeFilter ;-)

I assume there are some config parameters
to setup logging somewhere else.  If <realtime/> is
missing then the <rpc> finishes when all saved notifications have been
delivered. If present, then the <rpc> never finishes, and (in this
example) new notifications may be interleaved with saved notifications,
so the manager needs to check the timestamp as usual.

What about making it a generic RPC:

  <rpc>
    <get-log-records>
       <type>accounting</type>    <!-- or syslog or whatever -->
       <since>YYYY-MM-DD.HH:MM:SS</since>
       <realtime/>
    </get-log-records>
  </rpc>

> Thanks,
>  Phil

Andy

--
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: Andy Bierman <[email-masked]>
Date: Mon, 03 Apr 2006 08:37:15 -0700

> Is there interest in including replay in release one?

I'm interested in implementing what Phil is suggesting,
not the mechanisms in the current draft.

Andy

---

From: Shane Kerr <[email-masked]>
Date: Mon, 3 Apr 2006 17:43:26 +0200

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

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