SF in the mpCP. Since LSM events are only mapped on the parameters of invokes in an AMLn- SAG, this event can be handled as any other LSM event. CMIS/CMIP as well as CORBA do, however, perform mapping of LSM event on SAGs in a different way: 5.3 The Management Plane Control Point (mpCP) CMIS/CMIP is locked to the ROSE view on SAGs, which implies that the prim- itive type of a spontaneous events (Report in AMLs) must be mapped on the primitive types of a ROSE invoke. ROSE does not, however, define any primi- tive type for Report, since ROSE did assume that an object never generates any spontaneous event and only handles requests from the object user (which may or may not require an answer). Thus, spontaneous events must be mapped on a set of SAG primitives that are not suited for them. This complicates the handling of spontaneous events. The CMIS specification defines two "notification services" for CMIS users, a confirmed M-EVENT-REPORT and an unconfirmed one by the same name. In the CMIP specification is then defined how to map these services on "CMIP messages" and then on primitives of the ROSE-SAG. Besides the extra complexity caused by the CMIS/CMIP architecture, and the way mapping is done on the ROSE-SAG, the author feels it is rather strange to map an event report from an object in an AF on a primitive (the ROSE RO- INVOKE) that normally is used to carry requests for a remote party to execute an operation. This is especially peculiar since the event-generating object in the AF does not have a clue of what the OSF is going to do with the information. SNMP calls spontaneous events "traps", and defines a special message called SnmpV2-trap that is sent by an AF to an OSF when something unexpected hap- pens in the traffic system. The trap mechanism is rather simple: the message just says that something happened in the sending node but gives no details. The OSF must find out what it is by issuing queries on SNMP-MOs in AF by generating GET-requests. The trap mechanism comprises no confirming message from the OSF