San Diego OAM MIB summary

For those who weren't at the IETF meeting in San Diego, here are my notes received on the EFM OAM MIB.

1) Relationship to other MIBs.  There was a comment to add more verbage on the entirety of the EFM project to this MIB.  After a little discussion, it seemed like the consensus would be to add some text in the overview/background sections, but do not include anything in the actual MIB itself. 

2) Row status.  There were several tables with row status (dot3OamTable, dot3OamPeerTable).  This was commented as unnecessary and will be removed.

3) Special stuff for EPON.  A question was asked if anything special is needed for using OAM on EPON.  In general, EPON looks like a collection of p2p links to higher layer applications, OAM included but not special in that regard.  The suggestion at the end was to add a brief sentence somewhere that indicates EPON has an architecture for higher layer applications like OAM, reference the EPON MIB, but not go into any detail here.

4) Loopback control.  A comment was made that the OAM loopback control isn't secure.  In the end, the commentor misunderstood the intent/workings of the OAM loopback control objects and withdrew the comment after some discussion.  It was decided that OAM should not allow loopback commands from the peer by default (dot3OamLoopbackIgnoreRx=true by default).  

5) Event configuration.  A question was raised as to whether OAM should have a configurable number of re-tries for the event replication.  The idea would be to allow the administrator to configure whether an event should be sent once, twice, etc., in order to control the tradeoff between utilization and reliability (as OAM events are not confirmed or guaranteed).  Some discussion but no consensus, so if you have an opinion, pass it on.

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.  And that we might be able to create a generic event table rather than one row per event type.

7) Event compliance.  There was a question as to whether the compliance table should require implementation of all events, or if each event can be its own compliance group.  The justification for individual compliance groups for different events are that some can be implemented easier than others (e.g. remote fault may requrie hardware changes, frame error thresholds would not).  So the general feeling seemed to be that we can keep the individual event compliance groups. 

If anyone has a different recollection or additional opinionis, pass 'em on.

- Matt