Thanks for the comment. You have hit the nail on the head on separating the concerns for Business layer, Service layer and Technical layer of event engineering process. I do agree that the community can do more to provide meaningful details for event description but I believe fault reporting standards X.733 are handy reference for that but might be a little outdated.

Poorly defined events are at times a bigger problem than ‘outage’ itself. Another important dimension here is that contextual and organizational value of events is not communicated to all stakeholders. I plan to cover that in my upcoming posts.

Would it make sense if we divide the event processing process into two parts as expression of the business logic and low level technical handling?
It is true that it does not make sense to expect a tool to perform business functions, but it is understandable that people expect it to handle the low level technical functions.
Tools such as Mib2Rules can handle the low level activities and convert the machine language into human understandable standard. People need to do the rest to specify what to do with that information and express it as the business logic.

The real problem is (sadly) there is no open collaborative environment to express what events mean and what the relevant actions should be. Each organization is left to do this on its own (solve same problem repeatedly) and there is often not enough time/resources to do it, hence people/organizations looks for shortcuts, the magic wound.
There is great need/potential for collaboration in the event engineering process, unfortunately unlike developers, as IT management folks we suck at creating collaborative environments.