Re: [EFM-OAM] Notes from yesterday's call
Matt, one comment below:
At 04:19 PM 4/25/2003 -0400, Matt Squire wrote:
>Here are my notes from yesterday's call. Most of the time was spent
>walking thru Clause 30. Touched on some 22/36/45 things but not too much.
>
>Attendees: David Martin, David Law, Floyd Gerhardt, Barry O'Mahoney, Matt
>Squire
>
>- Matt
>
>=============================
>
>Clause30 Title. The current title doesn't address the new PHYs we now
>have. Should probably just call it "Management".
>
>Action. Matt to make comment.
>
>=============================
>
>Figs 30-3/30-4. Generally thought to be duplicates and that we can merge
>them.
>
>Action. DavidL to comment.
>
>
>=============================
>
>aSymbolErrorDuringCarrier. It wasn't obvious to those on the call how to
>interpret this attribute for copper (and maybe PON).
>
>Action. Ask those that know more how copper/P2MP fit into this.
>
>=============================
>
>Profiles. We asked if there were a way to have 10PASS-TS and 2PASS-TL use
>the same profile management structure. After some discussion, it didn't
>look like we could simplify it any.
>
>=============================
>
>Events. Lots of discussion on the events. First, we decided we need to
>have counters for the number of events, not just for the number of event
>PDUs (each PDU can contain multiple events of different types). Second,
>are unconfortable with the current C30 handling for events, where the
>latest received event info is an attribute. Given that this information
>can change multiple times per second, its quite possible that the changes
>would be missed. So it was suggested that instead of keeping the latest
>PDU info, we should only keep counters. Seemed like people wanted to
>think a little bit about that one.
Did anyone bring up Jonathon Thatcher's parallel counter idea (keeps a
running count, overflowing) from his comments on D1.3? Discussion was on
the reflector in late February 2003. Seems that could be a way to maintain
an accurate total count if we think we might miss an update, but maybe I'm
misinterpreting the concern above?
> Finally, it was pointed out that vendor specific event types are not
> covered and probably should be.
>
>Action: Matt to comment on event counters. Everyone to think about
>changing C30 event management philosophy to only counters rather than
>"last seen" event.
>Someone <forget if we had a volunteer> to comment about attribute(s)
>vendor extension events.
Thanks,
Brian