RE: FW: EPON MIB comments

> -----Original Message-----
> From: Matt Squire [mailto:[email protected]]
> > > 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.

Regards,

Dan


>