Subject: Event declarations

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Feb 2005 15:15:36 -0500

I am working on updating the model draft.
As part of that, I am trying to figure out where / how "events" should be 
declared.

The general idea is that the model will have event declarations, which also 
create a boolean variable.  When the variable is True, the event is sent.
I also assume that events will have a path to identify the event being 
signalled, and the event message will include an LFB instance 
identifier.  (The simplest model for achieving that I can see is that we 
have an "EVENT-REPORT" Operation, which carries path-data and content data 
for each event being reported.)

So now we turn to the model and ask the question "where should events be 
declared, and how should the content be declared?"

One way to do it is that each information declaration (structure, array, 
and LFB) caninclude its own event statement.  That statement would include 
a description of what the event means, and a declaration of the fields 
included in the data reported with the event.
This provides a nice simple consistent place to declare events.  The syntax 
would be clean.

But, it assumes that every LFB that wants to use a given type definition is 
going to want to be able to provide the same events.  Also, it would mean 
that the information reported by an event would have to come from that one 
structure.  Both these restrictions feel problematic to me.

The other alternative is to create an events section of the LFB declaration.
This would then need to somehow describe for each event what condition it 
is triggered by, and what information is sent.  The complication comes in 
when trying to declare evens triggered by entries in tables.  It is easy to 
have an LFB level event triggered by too many bad packets.  But suppose one 
has a port table, and the event is port down.  Clearly, the event should be 
tied to the individual port.  And clearly the reported elements should come 
from the corresponding failed element of the table.  And maybe from some 
parallel tables.
Hence, I start ending up with something in the LFB declaration that looks like:
    <event name=portfail, eventid = 700, varID = 17>
         <indexvariable> idx </indexvariable>
         <trigger> portstatus[idx} </trigger>
         <pathaugment> idx </pathaugment>
         <description> when status field becomes "down" <description>
         <report> portstatus[idx}.status, portinfo[idx].identity </report>
     </event>
So that you can have one or more index variables to use in referring to events.
you can indicate which ones are to appear in the event path and in what order
The trigger clause may be just documentation?
And the report clause, using the index variables, indicates what is to be 
reported.
And this would also declare a boolean array, with variable ID 17, to use to 
indicate which of these events are to be generated.

Is this a reasonable approach, or am I totally confused?
Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Feb 2005 16:14:43 -0500

> The other alternative is to create an events section of the LFB declaration.

This would be my preference. I dont like the previous scheme for reasons
you mentioned above.

>          <report> portstatus[idx}.status, portinfo[idx].identity </report>

I would see it slightly different.
You have a table of portevents, one per row.
The portevent definition will enumerate all possible port events and
associated  parameters and/or references of what to ship when
triggered... (something along the lines of what you have above but
loosing the indices and referencing/aliasing to the real data in the
attribute found in the PortTable attribute table).

i.e.

  <LFBClassDefs>
    <LFBClassDef>
       <capabilities>
          <capability>
           <name>PortCount</name>
           ...
           ...
        </capabilities>

      <Events>
        <Event>
          <name>EventPortTable</name>
          <id>4</id>
          <synopsis>table of Events one row per Port</synopsis>
          <typeRef>PortEvent</typeRef>
        </Event>
      </Events>

      <attributes>
        <attribute access="read-write">
          <name>PortTable</name>
          <id>3</id>
          <synopsis>table of Ports</synopsis>
          <typeRef>portdesc</typeRef>
        </attribute>
      </attributes>
    </LFBClassDef>
  </LFBClassDefs>

> you can indicate which ones are to appear in the event path and in what order

didnt follow.

> The trigger clause may be just documentation?

A triger could be a simple "it changed". Eg i may be interested when
someone changes the MTU or MAC address of an ethernet port. So
documentation maybe sufficient; i dont think you can come up with a
smart generic scheme to cover ranges etc. Maybe need to investigate
rmon.

One thing you havent mentioned is kicking of the event; in other words
registration; you need both a register/unregister which specifies a path
to the event of interest.
Registration also has hierachical semantics:
For example if i specify the path to be EventPortTable then i am
registering for all events for all ports.
If i specify a index to the table then i am registering only for that
port; if i specify a cell within a table then i am registering only for
that event within a port.

Theres also other sort of events that are interesting like "PortTable
has a new entry created for it"

> indicate which of these events are to be generated.

Well, I would see several levels of reporting - back to the other
favorite discussion
1) Event X that you registered for happened (eg "MTU on port 3 changed")
2) Event X that you registered for happened and heres the data (""MTU on
port 3 changed new value=Y")

> Is this a reasonable approach, or am I totally confused?

I think a good start for a discussion but we may have different
approaches.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 10 Feb 2005 16:30:13 -0500

A couple of questions that I think need to be elucidated:

Should the declaration make clear that this relates to the PortTable?
There are a number of different events that might be declared by the LFB 
designer.  Presumably, these need to be stated.  I would hope taht we are 
not requiring that the only granularity the LFB designer has is "there are 
events for any change to any structure element of this array, and for this 
array as a whole."
Should we distinguish between events that are changes to a table (creation, 
deletion), and events which are changes to values in one or more cells in a 
table?

Should the protocol support a short-hand for causing all events on all 
entries in a table to be reported?  (If so, we are going to have to be 
careful for the variable which controls events on the table, such as create 
and delete, and the variable which controls events on all elements of the 
table.)

It is clear that we want some events.
It is clear that having all possible events turned on all the time would be 
a bad thing.
So we need some declaration of events and some control over them.

But if we do not try to keep that simple, this is another place we could 
bury ourselves in complexity.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Feb 2005 16:59:35 -0500

On Thu, 2005-02-10 at 16:30, Joel M. Halpern wrote:
> designer.  Presumably, these need to be stated. 

Right - i see the declarations as <dataTypeDef> which may be grouped
together.
You have expressed dislike for this in the past or i may have
misunderstood you.

>  I would hope taht we are 

I think its valid to listen to events of that sort if you so wish (such
as registering to listen to all of the portevents). But i would say the
events need to be declared by the LFB definition author.

> deletion), and events which are changes to values in one or more cells in a 

I think so. Thos will be events other than EventPortTable events.

> entries in a table to be reported?

You mean like i stated in my other email in hierachies? I would say yes.

>   (If so, we are going to have to be 

makes sense.

> It is clear that we want some events.

yes ;->

> It is clear that having all possible events turned on all the time would be 

nod.

> So we need some declaration of events and some control over them.

yes indeed.

> bury ourselves in complexity.

I hear ya.

This thread is pretty green, hopefully we'll hear from some of the other
usual suspects.

cheers,
jamal