Subject: Re: Event subscription -- properties (model and protocol)

From: "Putzolu, David" <[email-masked]>
Date: Tue, 21 Jun 2005 08:45:50 -0700

Hi Joel.

I don't understand the following two sentences excerpted from 
your email - they seem to contradict each other to me. Can you 
elaborate a bit? 

"If the subscribe or unsubscribe is the event-base and the event-id, but

the event is defined in terms of a table, one has subscriber or 
unsubscribed to the entire table."

vs. 

"This does not allow for subscriber or unsubscribing in one reference to

either all events on a given table cell, or to all events on a given 
table. "

The first sentence seems to say for a table, subscribing "higher" in the
path subscribes to the whole thing.  The second seems to say one cannot
subscribe to the whole thing?

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, June 21, 2005 8:27 AM
To: [email-masked]
Subject: [FORCES] Event subscription -- properties (model and protocol)

In the last event description I sent to the list, I proposed that event 
information would have two IDs, one for identifying the event, and one
for 
indicating subscription to the event.

The properties information seems to create an opportunity to simplify 
this.  And to address some of the issue of aggregate registration.

Instead of declaring another ID, the subscription state of an event will
be 
part of its properties.  Thus, the properties returned for a
GET-PROPERTIES 
operation on an event path will include the event accessibility 
(unsupported, supported) and the subscription state.  Given that we may 
want to extend the subscription semantics, we will use an integer
variable, 
with 0 meaning not subscribed, and 1 meaning subscribed.
This then gives an easy way to subscribe or unsubscribe to all events
from 
the LFB, and to all instances of a given event on a table.
Remember that the event path will be event-base.event-id.subscripts 
(possibly with more than one subscript).  The subscripts indicate which 
table entry the event refers to.  Thus a subscriber or unsubscribe is a 
SET-PROPERTIES with a path.  If the path is just the event-base, one has

changed the subscription to all events for the LFB.  If the subscribe or

unsubscribe is the event-base and the event-id, but the event is defined
in 
terms of a table, one has subscriber or unsubscribed to the entire
table.
This does not allow for subscriber or unsubscribing in one reference to 
either all events on a given table cell, or to all events on a given 
table.  Given that presumably there are a modest number of events, it
seems 
a good trade to aggregate the table, while requiring explicit reference
to 
each event.

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jun 2005 12:03:40 -0400

Sorry I was unclear.  let me try an example.
Suppose that we have an LFB.
Suppose that it has a table X.  The contents of X are a structure with 
several fields, A, B, and C.

The event definitions define the path prefix 7 as meaning events.
Event ID 1 is defined as any change on field A of an entry in table X 
(hence the specific path is 7.1.subscript)
event ID 2 is defined as any change on field B of an entry in table X 
(hence the specific path is 7.2.subscript).
To subscribe to changes in the A field of the third table entry, one sets 
the subscribe field of the properties of path 7.1.3.
To subscribe to changes in the A field of any entry in table X, one sets 
the subscribe field of the properties of path 7.1
To subscribe to any events from the LFB, one sets the subscribe field of 
the path 7.

However, there is no path to subscribe to all the events on cell 3 of table 
X (7.1.3 and 7.2.3) nor is there a path to subscribe to all events on table 
X (7.1 and 7.2)

This is actually driven by simplicity, but makes sense to me because 7.1 
and 7.2 are easily known by the CE, while subscribing to every entry in the 
table individually, particularly when new entries are created, is harder.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 24 Jun 2005 07:03:50 -0400

> table individually, particularly when new entries are created, is harder.

I read the originating text and since this you have an example here,
this is probably the better example to jump to. 
I cant recall what our conclusion on this discussion was and i apologize
in advance if i am rehashing.
note: I agree with moving things into the properties of the events. 
I also see sense in the simplicity you introduce in the agregation.

One thing i am unsettled about still is the registration, in particular
with elements which present hierachies.

You know at table definition time what the columns are (A, B, C in your
example) - but you dont know the subscripts.
This leads to a challenge for subscription purposes in my view and i
think hierachical/coarse registration, bits of which you have in your
other text, is a good thing; for simplicty - a very fine grained
notification detail on the other is a good thing. Let me illustrate,
using your example and draw the relationship that makes sense to me for
both registration and notification. This is not an intuitive way to show
a table, but it makes sense for the way events should be and actually it
is the way you define event paths.
I introduce event ID 4 on top of your example.

   tableX (event ID 4)
      |
      +-- A (event ID 1)
      |   |
      |   +-- row 1
      |   |
      |   +-- row 2
      |   |
      .   .
      .   .
      |   +-- row n
      |   
      +-- B (event ID 2)
      |   |
      |   +-- row 1
      |   |
      |   +-- row 2
      |   |
      .   .
      .   .
      |   +-- row n
      |
      +-- C (event ID 3)
         |
         +-- row 1
         |
         +-- row 2
         |
         .
         .
         +-- row n 

Coarse Registration:
- I should be able to register to 7.1, 7.2, 7.3 or 7.4.
Note 7.4 covers the whole table (of course for event generating
elements). 

Fine grained registration:
Registering to 7.3.1 is harder in the case where the event to add such
an entry happens dynamically at the FE. It is easy to do if the CE adds
the entry for tableX, row 1.

Notification:
Notification will always have the details of what generated the event to
the finest grained level; example 7.3.1 even though i register for 7.3
or 7.4. 

Thoughts?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jun 2005 07:34:16 -0400

If I understand your suggestion, you are proposing that it be possible to 
add event declarations for targets without conditions.  These event ids / 
declarations are used only for registration (they would never  appear in 
notifications.
A registration for such an event constitutes a registration for every 
actual event that can be generated against the given target?

We can do that, but is it really worth it?  Aggregating subscripts is both 
natural and necessary, since there may be many of them, and they may be 
created at any time.  On the other hand, the events are known a priori to 
the CE, and there are not many.  The effort for the CE to register for the 
events is not much harder than the effort of registering for this 
aggregation event.
And I am somewhat uncomfortable with event declarations that are not events.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 24 Jun 2005 07:59:09 -0400

> declarations are used only for registration (they would never  appear in 

No they would appear in the notification.  Its up to the CE (if i
understood you correctly) to map them to something meaningful.

> actual event that can be generated against the given target?

Ok, i realize i was thinking narrowly basing on the scope of what we
have implemented to date. The only thing we are currently excited about
as far as event is of <change> nature (whether its ipsec, port LFB etc).
Thats the only events we have.
So my thoughts were along the mindset that the event type will be
homogenous across the table i.e all of A, B, and C throw <change> events
and i can therefore register for 7.4 ("the table events"). If the events
are not going to be homegenous then it is not worth it. If however, we
can leave that up to the CE it may be worth it.

> events is not much harder than the effort of registering for this 

I think we are partially agreeing:
If i heard you correctly you are saying i can register for agregated
events 7.1, 7.2, 7.3 and receive fine grained notifications for 7.1.1,
7.1.n etc. This i like.
What i also thought i heard you say is you cant register for aggregate
event 7.4 "the table events".  This is where we differ (given our
current implemented LFBs have homogenous event types).

> And I am somewhat uncomfortable with event declarations that are not events.

If 7.4 will introduce complexity to the model then i can live with the
CE translating it to mean {7.1, 7.2, 7.3}. It will help to explicitly
mention this in your text somewhere. It does seem to me like it would
ease things for the FE if i told it about 7.4 instead, no?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jun 2005 09:27:45 -0400

I can see how what you suggest would work if events were homogenous.  I 
don't think they are.
Given that they are not, I will try to add suitable explanatory text about 
what aggregations can and can not be registered for, and why.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 24 Jun 2005 09:38:22 -0400

> what aggregations can and can not be registered for, and why.

That would be fine with me. Thanks.

cheers,
jamal