rmonEventStatus

The status of a table entry.
          
Setting this object to the value invalid(4) has the
effect of invalidating the corresponding entry.
That is, it effectively disassociates the mapping
identified with said entry.
It is an implementation-specific matter as to whether
the agent removes an invalidated entry from the table.
Accordingly, management stations must be prepared to
receive tabular information from agents that corresponds
to entries currently not in use.  Proper
interpretation of such entries requires examination
of the relevant RmonStatus object.
          
An existing instance of this object cannot be set to
createRequest(2).  This object may only be set to
createRequest(2) when this instance is created.  When
this object is created, the agent may wish to create
supplemental object instances with default values
to complete a conceptual row in this table.  Because the
          
creation of these default objects is entirely at the option
of the agent, the manager must not assume that any will be
created, but may make use of any that are created.
Immediately after completing the create operation, the agent
must set this object to underCreation(3).
          
When in the underCreation(3) state, an entry is allowed to
exist in a possibly incomplete, possibly inconsistent state,
usually to allow it to be modified in multiple PDUs.  When in
this state, an entry is not fully active.
Entries shall exist in the underCreation(3) state until
the management station is finished configuring the entry
and sets this object to valid(1) or aborts, setting this
object to invalid(4).  If the agent determines that an
entry has been in the underCreation(3) state for an
abnormally long time, it may decide that the management
station has crashed.  If the agent makes this decision,
it may set this object to invalid(4) to reclaim the
entry.  A prudent agent will understand that the
management station may need to wait for human input
and will allow for that possibility in its
determination of this abnormally long period.
          
An entry in the valid(1) state is fully configured and
consistent and fully represents the configuration or
operation such a row is intended to represent.  For
example, it could be a statistical function that is
configured and active, or a filter that is available
in the list of filters processed by the packet capture
process.
          
A manager is restricted to changing the state of an entry in
the following ways:
          
     To:       valid  createRequest  underCreation  invalid
From:
valid             OK             NO             OK       OK
createRequest    N/A            N/A            N/A      N/A
underCreation     OK             NO             OK       OK
invalid           NO             NO             NO       OK
nonExistent       NO             OK             NO       OK
          
In the table above, it is not applicable to move the state
from the createRequest state to any other state because the
manager will never find the variable in that state.  The
nonExistent state is not a value of the enumeration, rather
it means that the entryStatus variable does not exist at all.
          
An agent may allow an entryStatus variable to change state in
additional ways, so long as the semantics of the states are
followed.  This allowance is made to ease the implementation of
the agent and is made despite the fact that managers should
never exercise these additional state transitions.