XEROX-GENERAL-MIB Table View

A table of general counters and capabilities for ease of use
of the XCMI General MIB on this host system.
          
Usage:  The ONLY valid row in the 'xcmGenBaseTable'
SHALL have an 'xcmGenBaseIndex' of one ('1').

A table of general localization information per device.  It is
put in a table so it can be per device using the hrDeviceIndex.

The available localizations in this device.

The current charset-indexed strings for this device.

The supported charsets for this device.

A table of fixed localization information per device.  It is
put in a table so it can be per device using the hrDeviceIndex.

A table containing 'advisory contention lock' objects for
various subtrees of MIB objects from the complete set of IETF
and XCMI MIB modules implemented by this host system.
          
Note:   To acquire an advisory lock on an ENTIRE host system,
a conforming management station (or management agent) SHALL
examine 'xcmGenLockCurrentMaxTimer', add an appropriate
delta for eventual processing, and lock the 'xcmGenLockTable'
itself.  When 'xcmGenLockCurrentLockCount' subsequently becomes
one (1), the requesting management station (or management agent)
has acquired a lock on the ENTIRE host system (since no OTHER
entity MAY acquire any further lock, because 'xcmGenLockTable'
has become 'read-only' to all other entities), and MAY proceed
accordingly.

A table containing information on a 'reconfiguration request',
for use in atomic reconfiguration of this host system.
          
Usage:  A conforming management station (or management agent)
SHALL lock 'xcmGenReconfTable' and 'xcmGenOptionTable'
before attempting to perform any 'reconfiguration request' on a
host system (via the 'xcmGenLockTable').

A table containing information on reconfiguration options,
for use in atomic reconfiguration of this host system.
          
Usage:  A conforming management station (or management agent)
SHALL lock 'xcmGenReconfTable' and 'xcmGenOptionTable'
before attempting to perform any 'reconfiguration request' on a
host system (via the 'xcmGenLockTable').
          
Note:   The 'xcmGenOptionTable' is indexed by 'hrDeviceIndex',
so the 'hrDeviceIndex' element of a columnar object instance ID
(ie, fully specified object identifier) NEED NOT be specified in
'xcmGenOptionTypeOID'.  To reconfigure objects indexed by
several devices in 'hrDeviceTable' of the IETF Host Resources
MIB (RFC 2790), a conforming management station SHALL use
several rows in 'xcmGenReconfTable' and several trees of objects
in 'xcmGenOptionTable' with appropriate 'hrDeviceIndex' values.
To reconfigure objects which are actually NOT indexed by
'hrDeviceIndex', it is RECOMMENDED that rows be used in
'xcmGenOptionTable' which are indexed by 'hrDeviceIndex' for an
'hrDeviceType' of 'hrDeviceUnknown'.

A table containing 'client data' objects for use by conforming
management stations/agents, particularly during installation
of this host system.
          
Usage:  For managed systems which support static rows (ie,
'read-write'), a management station (or management agent) SHALL
          
          
search 'xcmGenClientDataRowStatus', to determine the
appropriate value of 'xcmGenClientDataIndex' to use when
allocating an existing row in the 'xcmGenClientDataTable'.
          
Usage:  For managed systems which support dynamic rows (ie,
'read-create'), a management station (or management agent) SHALL
examine 'xcmGenClientDataLastIndex', to determine the
appropriate value of 'xcmGenClientDataIndex' to use when
creating a new row in the 'xcmGenClientDataTable'.
          
Usage:  Throughout this specification, the term 'stable storage'
refers to storage which is reliable over long durations (years)
and is NOT destroyed by host system reboot (eg, battery-backed
DRAM is 'stable storage' - while simple DRAM is NOT 'stable
storage').  Examples of valid 'stable storage' include:  NVRAM,
hard disk, EEPROM, etc.
          
Usage:  Conforming implementations SHALL preserve active
'client data' objects across management agent power cycles,
and SHALL implement one of the following two methods:
1)  The agent SHALL store 'client data' objects directly in
    'stable storage'; or
2)  The agent SHALL automatically checkpoint all active 'client
    data' objects to 'stable storage' with reasonable frequency
    (either due to a write to some 'client data' object, or upon
    expiration of a product-specific timeout).
          
Usage:  Conforming implementations MAY (optionally) support
one of the following two 'checkpoint protocols':
1)  A client sends a 'Set' of 'xcmGenClientDataRowStatus' to
    'active(1)', to request that a 'checkpoint' be performed;
2a) An agent which supports 'rapid checkpoint',
    completes the checkpoint to 'stable storage', and
    sends a 'SetResponse' with 'noError(0)';
    <or>
2b) An agent which supports 'delayed checkpoint',
    changes 'xcmGenClientDataRowStatus' to 'notInService(2)',
    sends a 'SetResponse' with 'noError(0)',
    completes the checkpoint to 'stable storage', and later
    changes 'xcmGenClientDataRowStatus' back to 'active(1)'.

A table of SNMP trap clients (management stations or proxies)
registered for trap delivery from this host system.
          
Usage:  SNMP version/transport independent trap registration.
          
          
Usage:  Conforming management stations SHALL create at
least one subordinate row in the 'xcmGenTrapViewTable' for each
trap client that they register in the 'xcmGenTrapClientTable'.
Conforming management agents SHOULD interpret a dangling row in
the 'xcmGenTrapClientTable' (no children) as 'NO traps in view'
(existing implementations of both clients and devices are known
to consider dangling rows invalid).  To register for all device
traps, use a single view of 'iso(1).org(3).dod(6).internet(1)'.
          
Usage:  Conforming management agents SHALL delete any
rows in the 'xcmGenTrapViewTable' which were subordinate to a
deleted row in the 'xcmGenTrapClientTable'.

A table of SNMP trap object subtrees (ie, trap scopes)
registered for trap delivery from this host system to the
associated trap client (management station or proxy).
          
Usage:  SNMP version/transport independent trap registration.
          
Usage:  Conforming management stations SHALL create at
least one subordinate row in the 'xcmGenTrapViewTable' for each
trap client that they register in the 'xcmGenTrapClientTable'.
Conforming management agents SHOULD interpret a dangling row in
the 'xcmGenTrapClientTable' (no children) as 'NO traps in view'
(existing implementations of both clients and devices are known
to consider dangling rows invalid).  To register for all device
traps, use a single view of 'iso(1).org(3).dod(6).internet(1)'.
          
Usage:  Conforming management agents SHALL delete any
rows in the 'xcmGenTrapViewTable' which were subordinate to a
deleted row in the 'xcmGenTrapClientTable'.

A table of message string labels for the current contents
of static (agent-generated) message string objects, in all
MIBs implemented by this host system.
          
Usage:  Exposes the server's message catalog for indirect search
          
          
via source message object OIDs, yielding message string labels.
          
Usage:  Supports reliable translation by clients (managers) of
static (agent-generated) message strings, INDEPENDENT of the
current language/country/charset of the message strings on the
managed host system in the conventional MIB objects.
          
Conformance:  XCMI conforming management agents SHALL
support SNMP Get requests to the 'xcmGenMessageMapTable'
(ie, agents must respond to valid explicit EXACT requests).
When 'xcmGenMessageMapTable' is currently 'hidden' via
'xcmGenBaseGroupWalkHidden', XCMI conforming management agents
SHALL skip over 'xcmGenMessageMapTable' to the next
lexicographically higher object for GetNext or GetBulk requests
- 'xcmGenMessageMapTable' SHOULD be invisible to MIB walks,
to avoid undesirable performance degradation with third-party
network management stations and other monitoring tools.

A table of message string translations for all target locales
of static (agent-generated) message string objects, in various
          
          
known (agent-supported) source message locales.
          
Usage:  Exposes the server's message catalog for indirect search
via source message object OIDs, yielding target string values.
          
Usage:  Supports reliable translation by servers (agents) of
static (agent-generated) message strings, INDEPENDENT of the
current language/country/charset of the message strings on the
managed host system in the conventional MIB objects.
          
Conformance:  XCMI conforming management agents SHALL
support SNMP Get requests to the 'xcmGenMessageTextTable'
(ie, agents must respond to valid explicit EXACT requests).
When 'xcmGenMessageTextTable' is currently 'hidden' via
'xcmGenBaseGroupWalkHidden', XCMI conforming management agents
SHALL skip over 'xcmGenMessageTextTable' to the next
lexicographically higher object for GetNext or GetBulk requests
- 'xcmGenMessageTextTable' SHOULD be invisible to MIB walks,
to avoid undesirable performance degradation with third-party
network management stations and other monitoring tools.

A table of notification rules (recipient/event lists)
registered for event delivery from this host system.
          
Note:   In this MIB, the term 'notification rule' is equivalent
to the term 'Subscription object' in IPP Notifications.
          
Usage:  Conforming management agents SHALL NOT accept sets to
any other columnar object in 'xcmGenNotifyRuleTable' when
'xcmGenNotifyRuleRowStatus' is 'active'.
Dynamic rows must be deleted (with 'destroy') and then recreated
(with 'createAndGo') with new columnar values.
Static rows must be released (with 'notInService') and then
then reallocated (with 'active') with new columnar values.
Thus only a row status transition to 'active' indicates a new
notification registration by a conforming management station.
          
Usage:  Conforming management agents SHALL delete any
rows in the 'xcmGenNotifyDetailTable' which were subordinate to
a deleted row in the 'xcmGenNotifyRuleTable'.

A 'sparse' table of notification detail information for
notification rules configured on this host system,
augmenting the basic entries in the 'xcmGenNotifyTable'.
          
Usage:  UNLIKE the 'xcmGenOptionTable' in the XCMI General MIB
(which is a unique exception), this table of 'dictionary-based'
notify details is used with DIRECT create/update operations.