POLICY-BASED-MANAGEMENT-MIB Table View

The policy table.  A policy is a pairing of a
policyCondition and a policyAction that is used to apply the
action to a selected set of elements.

The pmPolicyCodeTable stores the code for policy conditions and
actions.
          
An example of the relationships between the code table and the
policy table follows:
          
pmPolicyTable
    AdminGroup  Index   ConditionScriptIndex  ActionScriptIndex
A   ''          1       1                     2
B   'oper'      1       1                     2
C   'oper'      2       3                     4
          
pmPolicyCodeTable
AdminGroup  ScriptIndex  Segment    Note
          
''          1            1          Filter for policy A
''          2            1          Action for policy A
'oper'      1            1          Filter for policy B
'oper'      2            1          Action 1/2 for policy B
'oper'      2            2          Action 2/2 for policy B
'oper'      3            1          Filter for policy C
'oper'      4            1          Action for policy C
          
In this example, there are 3 policies: 1 in the '' adminGroup,
and 2 in the 'oper' adminGroup.  Policy A has been assigned
script indexes 1 and 2 (these script indexes are assigned out of
a separate pool per adminGroup), with 1 code segment each for
the filter and the action.  Policy B has been assigned script
indexes 1 and 2 (out of the pool for the 'oper' adminGroup).
While the filter has 1 segment, the action is longer and is
loaded into 2 segments.  Finally, Policy C has been assigned
script indexes 3 and 4, with 1 code segment each for the filter
and the action.

A registration table for element types managed by this
system.
          
The Element Type Registration table allows the manager to
learn what element types are being managed by the system and
to register new types, if necessary.  An element type is
registered by providing the OID of an SNMP object (i.e.,
without the instance).  Each SNMP instance that exists under
that object is a distinct element.  The index of the element is
the index part of the discovered OID.  This index will be
supplied to policy conditions and actions so that this code
can inspect and configure the element.
          
For example, this table might contain the following entries.
The first three are agent-installed, and the 4th was
downloaded by a management station:
          
OIDPrefix        MaxLatency  Description               StorageType
ifEntry          100 mS      interfaces - builtin      readOnly
0.0              100 mS      system element - builtin  readOnly
frCircuitEntry   100 mS      FR Circuits - builtin     readOnly
hrSWRunEntry     60 sec      Running Processes         volatile
          
Note that agents may automatically configure elements in this
table for frequently used element types (interfaces, circuits,
etc.).  In particular, it may configure elements for whom
discovery is optimized in one or both of the following ways:
          
1. The agent may discover elements by scanning internal data
   structures as opposed to issuing local SNMP requests.  It is
   possible to recreate the exact semantics described in this
   table even if local SNMP requests are not issued.
          
2. The agent may receive asynchronous notification of new
   elements (for example, 'card inserted') and use that
   information to instantly create elements rather than
   through polling.  A similar feature might be available for
   the deletion of elements.
          
Note that the disposition of agent-installed entries is
described by the pmPolicyStorageType object.

The pmRoleTable is a read-create table that organizes role
strings sorted by element.  This table is used to create and
modify role strings and their associations, as well as to allow
a management station to learn about the existence of roles and
their associations.
          
It is the responsibility of the agent to keep track of any
re-indexing of the underlying SNMP elements and to continue to
associate role strings with the element with which they were
initially configured.
          
Policy MIB agents that have elements in multiple local SNMP
contexts have to allow some roles to be assigned to elements
in particular contexts.  This is particularly true when some
elements have the same names in different contexts and the
context is required to disambiguate them.  In those situations,
a value for the pmRoleContextName may be provided.  When a
pmRoleContextName value is not provided, the assignment is to
the element in the default context.
          
Policy MIB agents that discover elements on other systems and
execute policies on their behalf need to have access to role
information for these remote elements.  In such situations,
role assignments for other systems can be stored in this table
by providing values for the pmRoleContextEngineID parameters.
          
For example:
Example:
element       role    context ctxEngineID   #comment
ifindex.1     gold                          local, default context
ifindex.2     gold                          local, default context
repeaterid.1  foo     rptr1                 local, rptr1 context
repeaterid.1  bar     rptr2                 local, rptr2 context
ifindex.1     gold    ''      A             different system
ifindex.1     gold    ''      B             different system
          
 The agent must store role string associations in non-volatile
 storage.

The pmCapabilitiesTable contains a description of
the inherent capabilities of the system so that
management stations can learn of an agent's capabilities and
differentially install policies based on the capabilities.
          
Capabilities are expressed at the system level.  There can be
variation in how capabilities are realized from one vendor or
model to the next.  Management systems should consider these
differences before selecting which policy to install in a
system.

The pmCapabilitiesOverrideTable allows management stations
to override pmCapabilitiesTable entries that have been
registered by the agent.  This facility can be used to avoid
situations in which managers in the network send policies to
a system that has advertised a capability in the
pmCapabilitiesTable but that should not be installed on this
particular system.  One example could be newly deployed
          
equipment that is still in a trial state in a trial state or
resources reserved for some other administrative reason.
This table can also be used to override entries in the
pmCapabilitiesTable through the use of the
pmCapabilitiesOverrideState object.  Capabilities can also be
declared available in this table that were not registered in
the pmCapabilitiesTable.  A management application can make
an entry in this table for any valid OID and declare the
capability available by setting the
pmCapabilitiesOverrideState for that row to valid(1).

This table defines schedules for policies.

The pmTrackingPETable describes what elements
are active (under control of) a policy.  This table is indexed
in order to optimize retrieval of the entire status for a
given policy.

The pmTrackingEPTable describes what policies
are controlling an element.  This table is indexed in
order to optimize retrieval of the status of all policies
active for a given element.

Policies that have debugging turned on will generate a log
entry in the policy debugging table for every runtime
exception that occurs in either the condition or action
code.
          
The pmDebuggingTable logs debugging messages when
policies experience run-time exceptions in either the condition
or action code and the associated pmPolicyDebugging object
has been turned on.
          
The maximum number of debugging entries that will be stored
and the maximum length of time an entry will be kept are an
implementation-dependent manner.  If entries must
be discarded to make room for new entries, the oldest entries
must be discarded first.
          
If the system restarts, all debugging entries may be deleted.