RE: FW: EPON MIB comments

> > > > Another example is alarm related attributes:
> > > > >    eponDeviceDyingGaspAlarmState
> > > > >    eponDeviceDyingGaspAlarmEnabled
> > > > >    eponDeviceCriticalEventState
> > > > >    eponDeviceCriticalEventEnabled
> > > > >    eponDeviceLocalLinkFaultAlarmState
> > > > >    eponDeviceLocalLinkFaultAlarmEnabled
> > 
> > In the first revision of the OAM MIB, these states were 
> > directly reflected.  In the -02 revision, all event 
> > information was shoved into a new "EventLog" table.  So 
> > transition in these are flags are reflected there.  I can add 
> > them back as separate objects, I just don't want to go back 
> > and forth.  In the transition to the -02 version, the 
> > enable/disable of the events reflected in flags was 
> > <stupidly> removed.  Can add that back as removing it was 
> > unintentional.  
> 
> unintentional - maybe
> stupid - I am not so sure :-)
> 
> The Alarm MIB (RFC 3877) can be used to define the alarms, 
> their severity status, and also defines a log. We can 
> consider using it, the balance being between the overhead of 
> supporting the full Alarm MIB vs. the benefit of avoiding duplication.

We talked about this a little bit at one of the IETF meetings a while back.  I had some simple "event status" objects defined at the time, and EPON had defined its own little event log.  The sense of the group was that I should EPON and OAM should define their own little event logs rather then try to leverage the alarm log.  

>From my notes (which I think were turned into your minutes):  
"
6) Event status table.  Currently, event information is stored as a TLV (e.g. an octet array).  The individual field are not pulled out and exposed.  A question was raised as to whether this is good or bad.  The positive aspects are that it results in fewer fields, but on the other side, the fields are probably useful and need to be exposed for a manager.  There seemed to be consensus that the fields should be pulled out of the TLV.  Also that we should be able to create a generic event table rather than one row per event type.
"

Hence we are where we are.  

- Matt