XEROX-HOST-RESOURCES-EXT-MIB: View SNMP OID List / Download MIB

Version: 5.602.pub The MIB module for extended configuration and management of various host resources for network accessible host systems. This module augments and extends the original IETF Host Resources MIB (RFC 2790). Usage: This MIB module introduces support for the 'realization' of both 'physical' and 'logical' devices, consistent with the Document Printing Application (DPA), ISO/IEC 10175, as reflected in the object 'xcmHrDevInfoRealization'. Note: Conforming implementations SHALL NOT 'bubble up' status from 'physical' devices to associated 'logical' devices. All devices SHALL report their own status ONLY. See: Section 9 'Supplement' in XCMI Extensions to IETF Host Resources TC, for implementation guidance for this MIB module. Copyright (C) 1995-2006 Xerox Corporation. All Rights Reserved.

The Host Resources Extensions MIB Device Info Group

The Host Resources Extensions MIB Device Help Group Implementation of this group is DEPRECATED (as of XCMI v4.1) and conforming implementations SHOULD use 'deviceHelp...' details in 'xcmHrDevDetailTable' instead.

The Host Resources Extensions MIB Device Mgmt Group

The Host Resources Extensions MIB Device Power Group

The Host Resources Extensions MIB Device Traffic Group

The Host Resources Extensions MIB System Fault Group

The Host Resources Extensions MIB General Group

The Host Resources Extensions MIB Device Calendar Group

The Host Resources Extensions MIB Software Running Ext Group

The Host Resources Extensions MIB Software Installed Ext Group

The Host Resources Extensions MIB Device Detail Group

The Host Resources Extensions MIB Storage Ext Group

The Host Resources Extensions MIB Storage Detail Group

The Host Resources Extensions MIB Device Cover Group

The Host Resources Extensions MIB Device Alert Group

The Host Resources Extensions MIB Console Screen Group

The Host Resources Extensions MIB Console Tab Group

The Host Resources Extensions MIB Supplies Group

The Host Resources Extensions MIB Detail Group

The Host Resources Extensions MIB Console Group

The compliance statements for SNMP management agents that implement the Host Resources Extensions MIB.

The value of the enterprise-specific OID in an SNMPv1 trap sent whenever a device status variable changes. See SNMPv2 trap definition 'xcmHrDevInfoV2Event' below for 'special semantics'.

This trap is sent whenever 'hrDeviceStatus' and/or 'xcmHrDevInfo[XStatus|Conditions|XConditions]' changes. Note: The variable-bindings of this trap have been chosen to specify a complete device status change while keeping trap messages reasonably concise (generally a few hundred octets at most). This notification has the following special semantics: o The device's 'hrDeviceIndex' field value SHALL be appended to this trap object ID, as a BER binary OID suffix. This trap OID qualifier allows device management/monitoring applications to limit the alerts they receive to ones generated by devices of interest.

A 'sparse' table containing device info objects for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790). Usage: Although this group is Mandatory in this MIB module, this table is 'sparse' because conforming management agents need NOT implement an entry in 'xcmHrDevInfoTable' for ALL of the installed (and instrumented) devices in 'hrDeviceTable'. Usage: Conforming management agents SHALL implement an entry in 'xcmHrDevInfoTable' for the following device types (if they are installed devices in 'hrDeviceTable'): 'hrDevicePrinter' (from IETF Host Resource MIB, RFC 2790); and 'xcmHrDeviceHostSystem', 'xcmHrDeviceScanner', 'xcmHrDeviceCopier', 'xcmHrDeviceFax', and 'xcmHrDeviceMailbox' (from XCMI HRX TC).

A 'sparse' entry containing device info objects for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrDevInfoTable' and ALSO manages the row status of the associated conceptual row in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790). Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevInfoRowStatus' row status object; and SHALL clear the 'xcmHrDevInfoGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevInfoRowStatus' row status object; and SHALL set the 'xcmHrDevInfoGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

Human-readable device name, used by system administrators and end users to identify this device for systems management. Usage: This device name SHALL be the one normally used in a CLI/GUI/API for control of this system or device (eg, 'showstopper.sample.com' or 'showstopper.sample.com/lpt1:') Usage: Conforming management agents, which ALSO implement the the Printer MIB v2, SHALL set 'xcmHrDevInfoName' to the SAME value as 'prtGeneralPrinterName' for the SAME 'hrDevicePrinter' row (i.e., the values of these two objects SHALL be interlocked).

Human-readable serial number, used by system administrators and end users to identify this device for systems management. Usage: Conforming management agents, which ALSO implement the the Printer MIB v2, SHALL set 'xcmHrDevInfoSerialNumber' to the SAME value as 'prtGeneralSerialNumber' for the SAME 'hrDevicePrinter' row (i.e., the values of these two objects SHALL be interlocked).

An extended device type (or device 'realization'), used by system administrators and end users of this device.

An extended device status, used by system administrators and end users of this device (here, read 'state' for 'status'). Usage: Conforming implementations SHALL NOT 'bubble up' status from 'physical' devices to associated 'logical' devices. All devices SHALL report their own status ONLY. Usage: Exactly one enumeration of extended device status SHALL be defined, with ranges for each basic device type (eg, 'hrDevicePrinter'). The legal range for extended device status for a given device type (either defined by RFC 2790 or by this MIB) is found by multiplying the final arc of the the device type OID by 100 - the result is the device specific range base - the end of the device specific range is 99 larger. These device specific extended device status values SHALL be reissued periodically in the 'XcmHrDevInfoXStatus' textual convention.

A relatively generic description of the current 'conditions' of this device, specified in a bit-mask. Usage: It is desirable that the implementor report 'conditions' of all devices corresponding to conceptual rows in the 'hrDeviceTable' as accurately as feasible. 'Conditions' occur within or across 'states' in a finite state machine (FSM) implementation of a device. They represent both short term and long term conditions.

A device specific description of the extended 'conditions' of this device, specified in a bit-mask. Usage: For FUTURE expansion. Usage: Exactly one bit mask of extended device conditions SHALL be defined for each basic device type (eg, 'hrDevicePrinter'). These device specific extended device conditions values SHALL be reissued periodically in the 'XcmHrDevInfoXConditions' textual convention. These device specific extended device conditions are mutually exclusive and 'overloaded' in the single reporting object 'xcmHrDevInfoXConditions'.

The date of the most recent install or upgrade of the device represented by this conceptual row in the 'hrDeviceTable'.

The date of the most recent auto or managed reset of the device represented by this conceptual row in the 'hrDeviceTable'.

The value of 'hrDeviceIndex' corresponding to: a) the next associated row in the 'hrDeviceTable'; or b) zero if this is the last associated conceptual row in a given set; or c) zero if this conceptual row is NOT part of a set.

The value of 'hrDeviceIndex' corresponding to: a) the previous associated row in the 'hrDeviceTable'; or b) zero if this is the first associated conceptual row in a given set; or c) zero if this conceptual row is NOT part of a set.

The value of 'hrDeviceIndex' corresponding to the directly associated conceptual row in the 'hrDeviceTable' representing: a) the first underlying 'physical' device (if any), if this row has 'xcmHrDevInfoRealization' of 'logical'; or b) the first subordinate 'physical' device (if any), if this row has 'xcmHrDevInfoRealization' of 'physical' or 'logicalAndPhysical'; or c) zero if there is no underlying or subordinate 'physical' device associated with this row (ie, this device).

The current priority of this device. Usage: The scheduling priority of this device, where '0' is unspecified (default), '1' is lowest, and '100' is highest.

Human-readable, alpha-numeric ID used by Xerox and Xerox managed service providers to uniquely identify a device ACROSS back-end financial, printer management, asset management, and help desk system applications. The Asset Tag Number is an infra- structure management de facto standard for asset identification for use by Xerox and Xerox managed service providers. Usage: Conforming management agents SHALL set 'xcmHrDevInfoXeroxAssetTagNumber' to the SAME value as entered at a device's local UI, at a device's web UI interface, and as shown on the device's configuration sheet.

Human-readable, alpha-numeric ID used by customers of Xerox. This ID is used system administrators and their designated managed service providers to uniquely identify a device for customers' internal financial management, printer management, asset management, and help desk system applications. Usage: Conforming management agents SHALL set 'xcmHrDevInfoCustomerAssetNumber' to the SAME value as entered at a device's local UI, at a device's web UI interface, and as shown on the device's configuration sheet.

An alpha-numeric ID used by Xerox and Xerox authorized resellers to enable devices to use a PagePack model of device distribution. PagePack is a cost per page contract model - which includes consumables, supplies and service - on both printer and multifunction systems The PIN number is used to change a device from purchased consumables device to a PagePack device. Usage: The device may return a NULL string or the word 'authorized' if the PIN value has been sent and the device does not want to expose the value to the PIN to unauthorized viewing. If no PIN has been sent or this functionality is not supported then a NULL string is returned

An enumeration used to get and set the page pack settings. Usage: The device will return enabled when page pack has been enabled and return disabled when page pack has been disabled. enabled (1) disabled (2)

An timer value for page pack. Usage: The value (-1) means timer not enabled and a value 0..2147483647 means the timer has been enabled

A 'sparse' table containing device help objects for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing device help objects for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrDevHelpTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevHelpRowStatus' row status object; and SHALL clear the 'xcmHrDevHelpGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevHelpRowStatus' row status object; and SHALL set the 'xcmHrDevHelpGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

Human-readable operator message, used by system operators and system administrators to display an operator message for end users of this device. For example, 'Out to lunch - back at 1pm'.

Human-readable problem message, used by system operators and system administrators to display a problem message for end users of this device. For example, 'Toner low - only small jobs accepted'.

The value of 'xcmCommsAddressIndex' corresponding to the first associated conceptual row in the 'xcmCommsAddressTable', or zero if this 'xcmHrDevHelpEntry' does NOT require such information. This 'chain' of address entries provides device help contact info for end users of this device. For example, 'system operator' or 'supplies' contact info.

The value of the enterprise-specific OID in an SNMPv1 trap sent whenever an 'xcmHrDevMgmtCommandRequest' completes. See SNMPv2 trap definition 'xcmHrDevMgmtV2Event' below for 'special semantics'.

This trap is sent whenever an 'XcmHrDevMgmtCommandRequest' completes, ie, when 'xcmHrDevMgmtCommandStatus' becomes the completed operation status and 'XcmHrDevMgmtCommandInProgress' goes from 'true' to 'false'. Note: The variable-bindings of this trap have been chosen to specify a complete management operation result while keeping trap messages reasonably concise (generally a few hundred octets at most). This notification has the following special semantics: o The device's 'hrDeviceIndex' field value SHALL be appended to this trap object ID, as a BER binary OID suffix. This trap OID qualifier allows device management/monitoring applications to limit the alerts they receive to ones generated by requests they have submitted.

A 'sparse' table containing management control objects for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing management control objects for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrDevMgmtTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevMgmtRowStatus' row status object; and SHALL clear the 'xcmHrDevMgmtGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevMgmtRowStatus' row status object; and SHALL set the 'xcmHrDevMgmtGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

The most recent device management command request specified for this conceptual row in the 'xcmHrDevMgmtTable'. Usage: Conforming management agents SHALL 'reject' any SNMP Set-Request to 'xcmHrDevMgmtCommand[Request|Data]' while another management operation is already in progress (ie, while 'xcmHrDevMgmtCommandInProgress' is 'true'), with 'badValue' (SNMPv1) or 'inconsistentValue' (SNMPv2/v3). Usage: Conforming management stations SHALL set 'xcmHrDevMgmtCommandRequest' (mgmt operation) and 'xcmHrDevMgmtCommandData' (mgmt arguments) SIMULTANEOUSLY (in the same SNMP Set-Request PDU).

The most recent device management command data (if any) specified for this conceptual row in the 'xcmHrDevMgmtTable'. Usage: Conforming management agents SHALL 'reject' any SNMP Set-Request to 'xcmHrDevMgmtCommand[Request|Data]' while another management operation is already in progress (ie, while 'xcmHrDevMgmtCommandInProgress' is 'true'), with 'badValue' (SNMPv1) or 'inconsistentValue' (SNMPv2/v3). Usage: Conforming management stations SHALL set 'xcmHrDevMgmtCommandRequest' (mgmt operation) and 'xcmHrDevMgmtCommandData' (mgmt arguments) SIMULTANEOUSLY (in the same SNMP Set-Request PDU). Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object.

The simple device management error status associated with this conceptual row in 'xcmHrDevMgmtTable'. Usage: Conforming management agents SHALL set this object to the value returned in an SNMP Set-Response PDU when a simple device management operation is 'accepted', ie, when 'xcmHrDevMgmtCommandInProgress' goes from 'false' to 'true'. Usage: Conforming management agents SHALL set this object to the value of the completion status of the (possibly deferred) simple device management operation, when 'xcmHrDevMgmtCommandInProgress' goes from 'true' to 'false'.

A protected end user password for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return a zero length string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an authenticated SNMP SetRequest changing the system 'end user password' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin]Password' in ciphertext (ie, encrypted) written in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin]Password' presented in client applications (eg, install tools). WARNING: Such authentication mechanisms do NOT protect managed systems from attack by other SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

A protected system operator password for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return a zero length string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an authenticated SNMP SetRequest changing the system 'operator password' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin]Password' in ciphertext (ie, encrypted) written in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin]Password' presented in client applications (eg, install tools). WARNING: Such authentication mechanisms do NOT protect managed systems from attack by other SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

A protected system administrator password for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return a zero length string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an authenticated SNMP SetRequest changing the system 'administrator password' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin]Password' in ciphertext (ie, encrypted) written in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin]Password' presented in client applications (eg, install tools). WARNING: Such authentication mechanisms do NOT protect managed systems from attack by other SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

The device management in progress status associated with this conceptual row in 'xcmHrDevMgmtTable'. Usage: Conforming management agents SHALL 'reject' any SNMP Set-Request to 'xcmHrDevMgmtCommand[Request|Data]' while another management operation is already in progress (ie, while 'xcmHrDevMgmtCommandInProgress' is 'true'), with 'badValue' (SNMPv1) or 'inconsistentValue' (SNMPv2/v3).

A protected end user Name for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return a zero length string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an authenticated SNMP SetRequest changing the system 'end user Name' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin]Name' in ciphertext (ie, encrypted) written in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin]Name' presented in client applications (eg, install tools). WARNING: Such authentication mechanisms do NOT protect managed systems from attack by other SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

A protected system operator Name for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return a zero length string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an authenticated SNMP SetRequest changing the system 'operator Name' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin]Name' in ciphertext (ie, encrypted) written in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin]Name' presented in client applications (eg, install tools). WARNING: Such authentication mechanisms do NOT protect managed systems from attack by other SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

A protected system administrator Name for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return a zero length string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an authenticated SNMP SetRequest changing the system 'administrator Name' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin]Name' in ciphertext (ie, encrypted) written in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin]Name' presented in client applications (eg, install tools). WARNING: Such authentication mechanisms do NOT protect managed systems from attack by other SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

A protected PDL password for this device. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object. Usage: All XCMI conforming management agents: a) SHOULD always return an encoded string in response to an SNMP GetRequest of this object; b) SHALL NOT return the contents of this object in cleartext (ie, unencrypted) in response to an SNMP GetRequest; c) SHOULD support (ie, accept) an unencoded SNMP SetRequest changing the system 'custom password' in this object. Usage: Conforming management stations and management agents SHOULD support authentication of SNMP SetRequests via values of 'xcmHrDevMgmt[User|Operator|Admin|Custom]Password' in written cleartext in 'xcmHrDevMgmtCommandData'. Usage: Conforming management stations MAY support client-side authentication of user roles and rights via checking values of 'xcmHrDevMgmt[User|Operator|Admin|Custom]Password' presented in client applications (eg, install tools). WARNING: Such mechanisms do NOT protect managed systems from attack by other authentication SNMP client applications that do NOT perform such client-side authentication and are thus inherently weak.

A 'sparse' table containing power management cycle objects for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing power management cycle objects for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrDevPowerTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevPowerRowStatus' row status object; and SHALL clear the 'xcmHrDevPowerGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevPowerRowStatus' row status object; and SHALL set the 'xcmHrDevPowerGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

A device 'warm up' feature support management object, used by system administrators of this device. Usage: This object specifies the support present (if any) for a device 'warm up' feature ('standbyMode' to 'readyMode'). For example, a photocopier might want to 'warm up' (as a system) (to 'readyMode') some time after a user presses a button. * 'other(1)' - DEPRECATED - SHALL NOT be used by conforming implementations * 'on(3)' - device 'warm up' feature is present and enabled both '...WarmUpDelay' and '...WarmUpDuration' are used - if '...WarmUpDelay' is zero, then 'warm up' cycle begins immediately after trigger event - if '...WarmUpDelay' is non-zero, then 'warm up' cycle is delayed for specified time - if '...WarmUpDuration' is zero, then 'warm up' cycle completes immediately after initiation - if '...WarmUpDuration' is non-zero, then 'warm up' cycle requires specified time to complete * 'off(4)' - device 'warm up' feature is present but disabled both '...WarmUpDelay' and '...WarmUpDuration' NOT used * 'notPresent(5)' - device 'warm up' feature NOT present on this host system both '...WarmUpDelay' and '...WarmUpDuration' NOT used

A device 'cool down' feature support management object, used by system administrators of this device. Usage: This object specifies the support present (if any) for a device 'cool down' feature ('readyMode' to 'standbyMode'). For example, a printer might want to 'cool down' a motor (to 'standbyMode') some time after the last page printed. * 'other(1)' - DEPRECATED - SHALL NOT be used by conforming implementations * 'on(3)' - device 'cool down' feature is present and enabled both '...CoolDownDelay' and '...CoolDownDuration' are used - if '...CoolDownDelay' is zero, then 'cool down' cycle begins immediately after trigger event - if '...CoolDownDelay' is non-zero, then 'cool down' cycle is delayed for specified time - if '...CoolDownDuration' is zero, then 'cool down' cycle completes immediately after initiation - if '...CoolDownDuration' is non-zero, then 'cool down' cycle requires specified time to complete * 'off(4)' - device 'cool down' feature is present but disabled both '...CoolDownDelay' and '...CoolDownDuration' NOT used * 'notPresent(5)' - device 'cool down' feature NOT present on this host system both '...CoolDownDelay' and '...CoolDownDuration' NOT used

A device 'energy save' feature support management object, used by system administrators of this device. Usage: This object specifies the support present (if any) for a device 'energy save' feature ('standbyMode' to 'sleepMode'). For example, a printer might want to 'energy save' transition (to 'sleepMode') some time after the last 'cool down' (to 'standbyMode') completion. * 'other(1)' - DEPRECATED - SHALL NOT be used by conforming implementations * 'on(3)' - device 'energy save' feature is present and enabled both '...EnergySaveDelay' and '...EnergySaveDuration' are used - if '...EnergySaveDelay' is zero, then 'energy save' cycle begins immediately after trigger event - if '...EnergySaveDelay' is non-zero, then 'energy save' cycle is delayed for specified time - if '...EnergySaveDuration' is zero, then 'energy save' cycle completes immediately after initiation - if '...EnergySaveDuration' is non-zero, then 'energy save' cycle requires specified time to complete * 'off(4)' - device 'energy save' feature is present but disabled both '...EnergySaveDelay' and '...EnergySaveDuration' NOT used * 'notPresent(5)' - device 'energy save' feature NOT present on this host system both '...EnergySaveDelay' and '...EnergySaveDuration' NOT used

A device power cycle time unit, used by system administrators of this device for power management cycle times. Usage: Used to scale the values in the Device Power group, for convenience and (optional) high resolution.

A device 'warm up' feature delay time, or zero if none, used by system administrators of this device. Usage: The time delay after last 'warm up' trigger event (eg, arrival of a job, some local user action, etc) before the 'warm up' cycle will begin (to power 'readyMode' in 'xcmHrDevInfoConditions').

A device 'warm up' feature duration, or zero if none, used by system administrators of this device. Usage: The time after last 'warm up' initiation before the 'warm up' will complete (to power 'readyMode' in 'xcmHrDevInfoConditions').

A device 'cool down' feature delay time, or zero if none, used by system administrators of this device. Usage: The time delay after last 'cool down' trigger event (eg, completion of a job, some local user action, etc) before the 'cool down' cycle will begin (to power 'standbyMode' in 'xcmHrDevInfoConditions').

A device 'cool down' feature duration, or zero if none, used by system administrators of this device. Usage: The time after last 'cool down' initiation before the 'cool down' will complete (to power 'standbyMode' in 'xcmHrDevInfoConditions').

A device 'energy save' feature delay time, or zero if none, used by system administrators of this device. Usage: The time delay after last 'energy save' trigger event (eg, completion of the last 'cool down' cycle to 'standbyMode') before the 'energy save' cycle will begin (to power 'sleepMode' in 'xcmHrDevInfoConditions').

A device 'energy save' feature duration, or zero if none, used by system administrators of this device. Usage: The time after last 'energy save' initiation before the 'energy save' will complete (to power 'sleepMode' in 'xcmHrDevInfoConditions').

A device 'wake up' feature support management object, used by system administrators of this device. Usage: This object specifies the support present (if any) for a device 'wake up' feature ('sleepMode' to 'standbyMode'). For example, a photocopier might want to 'wake up' (as a system) (to 'standbyMode') some time after a user presses a button. * 'other(1)' - DEPRECATED - SHALL NOT be used by conforming implementations * 'on(3)' - device 'wake up' feature is present and enabled both '...WakeUpDelay' and '...WakeUpDuration' are used - if '...WakeUpDelay' is zero, then 'wake up' cycle begins immediately after trigger event - if '...WakeUpDelay' is non-zero, then 'wake up' cycle is delayed for specified time - if '...WakeUpDuration' is zero, then 'wake up' cycle completes immediately after initiation - if '...WakeUpDuration' is non-zero, then 'wake up' cycle requires specified time to complete * 'off(4)' - device 'wake up' feature is present but disabled both '...WakeUpDelay' and '...WakeUpDuration' NOT used * 'notPresent(5)' - device 'wake up' feature NOT present on this host system both '...WakeUpDelay' and '...WakeUpDuration' NOT used

A device 'wake up' feature delay time, or zero if none, used by system administrators of this device. Usage: The time delay after last 'wake up' trigger event (eg, arrival of a job, some local user action, etc) before the 'wake up' cycle will begin (to power 'standbyMode' in 'xcmHrDevInfoConditions').

A device 'wake up' feature duration, or zero if none, used by system administrators of this device. Usage: The time after last 'wake up' initiation before the 'wake up' will complete (to power 'standbyMode' in 'xcmHrDevInfoConditions').

A device 'shutdown' feature delay time, or zero if none, used by system administrators of this device. Usage: The time delay after last 'shutdown' trigger event (eg, completion of the last 'energy save' cycle to 'sleepMode') before the 'shutdown' cycle will begin (to power 'offMode' in 'xcmHrDevInfoConditions' and 'down' in 'hrDeviceStatus').

A device 'shutdown' feature duration, or zero if none, used by system administrators of this device. Usage: The time after last 'shutdown' initiation before the 'shutdown' cycle will complete (to power 'offMode' in 'xcmHrDevInfoConditions' and 'down' in 'hrDeviceStatus').

A device 'startup' feature delay time, or zero if none, used by system administrators of this device. Usage: The time delay after last 'startup' trigger event (eg, 'xcmHrDevCalendarCommandRequest' or local user action) before the 'startup' cycle will begin (to power 'readyMode' in 'xcmHrDevInfoConditions' and 'running' in 'hrDeviceStatus').

A device 'startup' feature duration, or zero if none, used by system administrators of this device. Usage: The time after last 'startup' initiation before the 'startup' cycle will complete (to power 'readyMode' in 'xcmHrDevInfoConditions' and 'running' in 'hrDeviceStatus').

A 'sparse' table containing traffic information objects for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing traffic information objects for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrDevTrafficTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevTrafficRowStatus' row status object; and SHALL clear the 'xcmHrDevTrafficGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevTrafficRowStatus' row status object; and SHALL set the 'xcmHrDevTrafficGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

A device input traffic support management object, used by system administrators of this device. Usage: This object specifies the support present (if any) for device input traffic (I/O). For example, a ROM only supports input traffic (ie, reads). * 'other(1)' - DEPRECATED - SHALL NOT be used by conforming implementations * 'on(3)' - device 'input I/O' feature is present and enabled and '...InputTimeout' is meaningful - if '...InputTimeout' is zero, then 'input I/O' cycle MAY proceed for an infinite time - if '...InputTimeout' is non-zero, then 'input I/O' cycle is limited to the specified time * 'off(4)' - device 'input I/O' feature is present but disabled and '...InputTimeout' is ignored * 'notPresent(5)' - device 'input I/O' feature NOT present on this host system and '...InputTimeout' is ignored

A device output traffic support management object, used by system administrators of this device. Usage: This object specifies the support present (if any) for device output traffic (I/O). For example, a ROM does NOT support output traffic (ie, writes). * 'other(1)' - DEPRECATED - SHALL NOT be used by conforming implementations * 'on(3)' - device 'output I/O' feature is present and enabled and '...OutputTimeout' is meaningful - if '...OutputTimeout' is zero, then 'output I/O' cycle MAY proceed for an infinite time - if '...OutputTimeout' is non-zero, then 'output I/O' cycle is limited to the specified time * 'off(4)' - device 'output I/O' feature is present but disabled and '...OutputTimeout' is ignored * 'notPresent(5)' - device 'output I/O' feature NOT present on this host system and '...OutputTimeout' is ignored

A device input unit, used by system administrators of this device for input traffic counters. Usage: For example, a disk drive might use 'mediaBlock'. Usage: Thanks to XCMI WG members for stimulating the following discussion. There are three reasonable ways for using the 'xcmHrDevTraffic[Input|Output]Unit' objects: a) 'read-only' and set up by the management agent according to the sole appropriate (fixed) units at time of row creation; b) 'write-once' by the management station, at time of row creation (possibly selecting from among several possible valid units); and c) 'write-many' by the management station (to dynamically request the management agent to 'convert' the 'xcmHrDevTraffic[Input|Output]Count' objects into the appropriate units). Conforming implementations need NOT support more than one of the above three scenarios. Usage: 'mediaImage' - SHOULD be used ONLY for softcopy INPUT page images (scan, copy, fax, etc.). 'mediaImpression' - SHOULD be used ONLY for hardcopy OUTPUT page impressions (print, copy, fax, etc.) 'mediaSheet' - SHOULD be used ONLY for hardcopy OUTPUT and does NOT always equal output pages (e.g., duplex or N-up printing).

A device output unit, used by system administrators of this device for output traffic counters. Usage: For example, a terminal might use 'textLine'. Usage: 'mediaImage' - SHOULD be used ONLY for softcopy INPUT page images (scan, copy, fax, etc.). 'mediaImpression' - SHOULD be used ONLY for hardcopy OUTPUT page impressions (print, copy, fax, etc.) 'mediaSheet' - SHOULD be used ONLY for hardcopy OUTPUT and does NOT always equal output pages (e.g., duplex or N-up printing).

A device input traffic count, used by system administrators and end users of this device. Usage: Although no default value ('DEFVAL' clause) is permitted (by IETF SMIv2) for this counter, conforming host systems SHALL zero this counter upon conceptual row creation.

A device output traffic count, used by system administrators and end users of this device. Usage: Although no default value ('DEFVAL' clause) is permitted (by IETF SMIv2) for this counter, conforming host systems SHALL zero this counter upon conceptual row creation.

A device input maximum size, or zero if infinite, used by system administrators and end users of this device. Usage: It is device specific how (or if) this limit object is used (eg, disk with 'xcmHrDevTrafficInputUnit' of 'mediaBlock' might limit block count of a single disk read to '50').

A device output maximum size, or zero if infinite, used by system administrators and end users of this device. Usage: It is device specific how (or if) this limit object is used (eg, disk with 'xcmHrDevTrafficOutputUnit' of 'mediaBlock' might limit block count of a single disk write to '50').

A device input traffic timeout (in seconds), or zero if none, used by system administrators of this device. Usage: This object specifies the timeout to be used (if any) for device input traffic (I/O). For example, a disk drive might want to timeout disk reads.

A device output traffic timeout (in seconds), or zero if none, used by system administrators of this device. Usage: This object specifies the timeout to be used (if any) for device output traffic (I/O). For example, a terminal might want to timeout screen writes.

A table of the system faults which have been recorded (logged) on this host system. Usage: Conforming implementations SHALL ensure that this table contains (up to) a product specific number of the most 'recent' faults on this host system. Usage: Conforming implementations which also implement Device Alert group, SHALL record in 'xcmHrDevAlertTable' each persistent system fault when it occurs and is recorded in 'xcmHrSystemFaultTable'. Usage: Conforming implementations MAY 'age' older entries out of 'xcmHrSystemFaultTable' (by an algorithm outside the scope of XCMI specifications).

An entry for a system fault which has been recorded (logged) on this host system.

A unique value used by this host system to identify this conceptual row in the 'xcmHrSystemFaultTable'. Usage: Conforming implementations SHALL NOT 'reuse' values of 'xcmHrSystemFaultIndex' until its' 32-bit value wraps. Even in the case of eventual wrap, the entries SHALL be strictly sequenced by the associated value of 'xcmHrSystemFaultDate'. Usage: Conforming implementations are strongly encouraged to preserve the last used value of 'xcmHrSystemFaultIndex' across system power cycles.

This object is used to create (by management agent) and delete (by management station and/or management agent) individual conceptual rows in the 'xcmHrSystemFaultTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrSystemFaultRowStatus' row status object; and SHALL clear the 'xcmHrSystemFaultGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrSystemFaultRowStatus' row status object; and SHALL set the 'xcmHrSystemFaultGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

Encoded fault code of the system fault which is recorded in this conceptual row in the 'xcmHrSystemFaultTable'.

Human-readable fault string of the system fault which is recorded in this conceptual row in the 'xcmHrSystemFaultTable'.

An (optional) unambiguous system object reference (which MAY include instance suffix information), used by system administrators and end users to qualify this system fault. Usage: Since this system object reference is specified as an object identifier, it MAY be taken from any IETF, Xerox, third- party, or product-specific MIB, or it MAY simply be any IETF SMIv2-style 'autonomous type'.

An (optional) device index (ie, value of 'hrDeviceIndex'), used by system administrators and end users to qualify this system fault.

The time stamp for the system fault which is recorded in this conceptual row in the 'xcmHrSystemFaultTable'.

A table of general counters and information for ease of use of the XCMI Ext to IETF Host Resources MIB and the IETF Host Resources MIB (RFC 2790) on this host system. Usage: The ONLY valid row in the 'xcmHrGeneralTable' SHALL have an 'xcmHrGeneralIndex' of one ('1').

An entry of general counters and information for ease of use of the XCMI Ext to IETF Host Resources MIB and the IETF Host Resources MIB (RFC 2790) on this host system. Usage: The ONLY valid row in the 'xcmHrGeneralTable' SHALL have an 'xcmHrGeneralIndex' of one ('1').

A unique value used by this host system to identify this conceptual row in the 'xcmHrGeneralTable'. Usage: The ONLY valid row in the 'xcmHrGeneralTable' SHALL have an 'xcmHrGeneralIndex' of one ('1').

This object is used to display status of the ONLY valid conceptual row in the 'xcmHrGeneralTable'. Usage: 'xcmHrGeneralRowStatus' is 'read-only' because the ONLY valid conceptual row SHALL NOT be deleted.

The software product ID of the SNMP sub-agent which implements the IETF Host Resources MIB (RFC 2790) and XCMI Extensions to Host Resources MIB on this host system. Usage: This object SHALL specify the software product ID of an SNMP sub-agent (possibly also found in a conceptual row in the 'hrSWRunTable' and/or 'hrSWInstalledTable' in the IETF HR MIB). This object SHALL NOT specify a particular release of the IETF HR MIB, the XCMI HRX MIB, or the whole host system product. Note: Contrast with 'sysObjectID' for the whole SNMP agent in the IETF MIB-II (RFC 1213) and 'hrDeviceID' for the whole device (or whole product, in the case of 'xcmHrDevice...') in the IETF Host Resources MIB (RFC 2790).

The software build date of the SNMP sub-agent which implements the IETF Host Resources MIB (RFC 2790) and XCMI Extensions to Host Resources MIB on this host system. Usage: This object SHALL specify the BUILD date of the SNMP sub-agent software (not available elsewhere in IETF/XCMI MIBs). This object SHALL NOT specify the INSTALL date of the SNMP sub-agent software on this host system, nor the RESET date. Note: Contrast with 'hrSWInstalledDate' in the Software Installed group of the IETF Host Resources MIB (RFC 2790), and 'xcmHrDevInfoResetDate' in the Device Info group of the XCMI Host Resources Extensions MIB.

The terse conformance statement of ALL mandatory, conditionally mandatory, and optional IETF Host Resources MIB (RFC 2790) and XCMI Ext to IETF Host Resources MIB objects which are supported by this management agent implementation (ie, version) on this host system, specified in a bit-mask. Usage: Conforming management agents SHALL accurately report their support for IETF Host Resources MIB (RFC 2790) and XCMI Ext to IETF Host Resources MIB object groups.

The last entry index (regardless of its current state) in the 'hrStorageTable' of the IETF Host Resources MIB, on this host system. Usage: The last entry index explicitly bounds the valid range of 'hrStorageIndex'.

The last entry index (regardless of its current state) in the 'hrDeviceTable' of the IETF Host Resources MIB, on this host system. Usage: The last entry index explicitly bounds the valid range of 'hrDeviceIndex'.

The last entry index (regardless of its current state) in the 'hrFSTable' of the IETF Host Resources MIB, on this host system. Usage: The last entry index explicitly bounds the valid range of 'hrFSIndex'.

The last entry index (regardless of its current state) in the 'hrSWRunTable' of the IETF Host Resources MIB, on this host system. Usage: The last entry index explicitly bounds the valid range of 'hrSWRunIndex'.

The last entry index (regardless of its current state) in the 'hrSWInstalledTable' of the IETF Host Resources MIB, on this host system. Usage: The last entry index explicitly bounds the valid range of 'hrSWInstalledIndex'.

The last entry index (regardless of its current state) in the 'xcmHrSystemFaultTable' of this XCMI Ext to Host Resources MIB, on this host system. Usage: The last entry index explicitly bounds the valid range of 'xcmHrSystemFaultIndex'.

The terse conformance statement of ALL mandatory, conditionally mandatory, and optional IETF Host Resources MIB (RFC 2790) and XCMI Ext to IETF Host Resources MIB objects which are supported for dynamic row creation (via '...RowStatus') by this management agent implementation (ie, version) on this host system, specified in a bit-mask. Usage: Conforming management agents SHALL accurately report their support for IETF Host Resources MIB (RFC 2790) and XCMI Ext to IETF Host Resources MIB object groups.

The terse conformance statement of ALL mandatory, conditionally mandatory, and optional IETF Host Resources MIB (RFC 2790) and XCMI Ext to IETF Host Resources MIB objects which are supported for existing row update (via SNMP Set-Request PDUs) by this management agent implementation (ie, version) on this host system, specified in a bit-mask. Usage: Conforming management agents SHALL accurately report their support for IETF Host Resources MIB (RFC 2790) and XCMI Ext to IETF Host Resources MIB object groups.

A 'sparse' table containing calendar management objects for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing calendar management objects for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

The day of week when the command specified in this conceptual row in the 'xcmHrDevCalendarTable' SHALL be invoked.

The time of day when the command specified in this conceptual row in the 'xcmHrDevCalendarTable' SHALL be invoked, specified as hours (0..23) multiplied by 100, added to minutes (0..59), added to a constant bias of 10000 (avoids an index value of zero in 'xcmHrDevCalendarTimeOfDay').

This object manages the row status of this conceptual row in the 'xcmHrDevCalendarTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevCalendarRowStatus' row status object; and SHALL clear the 'xcmHrDevCalendarGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevCalendarRowStatus' row status object; and SHALL set the 'xcmHrDevCalendarGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

The explicit date when the command specified in this conceptual row in the 'xcmHrDevCalendarTable' SHALL be invoked. Usage: When 'xcmHrDevCalendarExplicitDate' is used, the value of 'xcmHrDevCalendarDayOfWeek' SHALL be 'everyDay' and the value of 'xcmHrDevCalendarTimeOfDay' SHALL be arbitrary (to provide uniqueness for this conceptual row).

The management command request specified in this conceptual row in the 'xcmHrDevCalendarTable', which SHALL be invoked based on 'xcmHrDevCalendarDayOfWeek', 'xcmHrDevCalendarTimeOfDay', and (optionally) 'xcmHrDevCalendarExplicitDate'.

The management command data specified in this conceptual row in the 'xcmHrDevCalendarTable', which SHALL be invoked based on 'xcmHrDevCalendarDayOfWeek', 'xcmHrDevCalendarTimeOfDay', and (optionally) 'xcmHrDevCalendarExplicitDate'. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object.

A 'sparse' table containing software info objects for loaded and (possibly) active software on this host system, augmenting the basic entries in the 'hrSWRunTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing software info objects for loaded and (possibly) active software on this host system, augmenting a basic entry in the 'hrSWRunTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrSWRunTable' and ALSO manages the row status of the associated conceptual row in the 'hrSWRunTable' of the IETF Host Resources MIB. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrSWRunRowStatus' row status object; and SHALL clear the 'xcmHrSWRunGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrSWRunRowStatus' row status object; and SHALL set the 'xcmHrSWRunGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

Human-readable software name, used by system administrators and end users to identify this software for systems management. Usage: This software name SHALL be the one normally used in a CLI/GUI/API for control of this software. Note: The 'hrSWRunName' object in 'hrSWRunTable' of the IETF Host Resources MIB (RFC 2790) has MANDATORY content of 'manufacturer, revision, and the name by which [the software] is commonly known'. Thus, conforming implementations SHALL NOT set a 'simple name' into 'hrSWRunName'. Therefore, this 'xcmHrSWRunAdminName' object is needed for management.

An extended software status, used by system administrators and end users of this software (here, read 'state' for 'status'). Note: This extended software status is present for future extensions.

The date and time when this conceptual row was created.

The value of 'hrDeviceIndex' corresponding to the first associated conceptual row in the 'hrDeviceTable' representing a supported and (possibly) ready 'physical' device, which has 'xcmHrDevInfoRealization' of 'physical' or 'logicalAndPhysical', or zero, if there is no supported and subordinate 'physical' device associated with this row (ie, this running software).

The value of 'hrDeviceIndex' corresponding to the first associated conceptual row in the 'hrDeviceTable' representing a supported and (possibly) ready 'logical' device, which has 'xcmHrDevInfoRealization' of 'logical' or 'logicalAndPhysical', or zero, if there is no supported and subordinate 'logical' device associated with this row (ie, this running software).

The value of 'hrSWRunIndex' corresponding to the next associated row in the 'hrSWRunTable', or zero if this is the last associated conceptual row in a given set.

The value of 'hrSWRunIndex' corresponding to the previous associated row in the 'hrSWRunTable', or zero if this is the first associated conceptual row in a given set.

A 'sparse' table containing software info objects for installed and (possibly) active software on this host system, augmenting the basic entries in the 'hrSWInstalledTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing software info objects for installed and (possibly) active software on this host system, augmenting a basic entry in the 'hrSWInstalledTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrSWInstalledTable' and ALSO manages the row status of the associated conceptual row in the 'hrSWInstalledTable' of the IETF Host Resources MIB (RFC 2790). Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrSWInstalledRowStatus' row status object; and SHALL clear the 'xcmHrSWInstalledGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrSWInstalledRowStatus' row status object; and SHALL set the 'xcmHrSWInstalledGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

Human-readable software name, used by system administrators and end users to identify this software for systems management. Usage: This software name SHALL be the one normally used in a CLI/GUI/API for control of this software. Note: The 'hrSWInstalledName' object in 'hrSWInstalledTable' of the IETF Host Resources MIB (RFC 2790) has MANDATORY content of 'manufacturer, revision, and the name by which [the software] is commonly known'. Thus, conforming implementations SHALL NOT set a 'simple name' into 'hrSWInstalledName'. Therefore, this 'xcmHrSWInstalledAdminName' object is needed for management.

An extended software status, used by system administrators and end users of this software (here, read 'state' for 'status'). Note: This extended software status is present for future extensions.

The date and time when this conceptual row was created.

The value of 'hrDeviceIndex' corresponding to the first associated conceptual row in the 'hrDeviceTable' representing a supported and (possibly) ready 'physical' device, which has 'xcmHrDevInfoRealization' of 'physical' or 'logicalAndPhysical', or zero, if there is no supported and subordinate 'physical' device associated with this row (ie, this installed software).

The value of 'hrDeviceIndex' corresponding to the first associated conceptual row in the 'hrDeviceTable' representing a supported and (possibly) ready 'logical' device, which has 'xcmHrDevInfoRealization' of 'logical' or 'logicalAndPhysical', or zero, if there is no supported and subordinate 'logical' device associated with this row (ie, this installed software).

The value of 'hrSWInstalledIndex' corresponding to the next associated row in the 'hrSWInstalledTable', or zero if this is the last associated conceptual row in a given set.

The value of 'hrSWInstalledIndex' corresponding to the previous associated row in the 'hrSWInstalledTable', or zero if this is the first associated conceptual row in a given set.

The value of the enterprise-specific OID in an SNMPv1 trap sent whenever a device detail usage or time limit is reached. See SNMPv2 trap definition 'xcmHrDevDetailV2Event' below for 'special semantics'.

This trap is sent when 'xcmHrDevDetailIndex' is shared between a counter detail and a limit detail which are specified in 'xcmHrDevDetailValueInteger', OR when 'xcmHrDevDetailValueString' specifies a trigger date. Note: The variable-bindings of this trap have been chosen to specify a complete device status change while keeping trap messages reasonably concise (generally a few hundred octets at most). This notification has the following special semantics: o The detail's 'hrDeviceIndex' value, the detail's 'xcmHrDevDetailType' value, and the detail's 'xcmHrDevDetailIndex' value SHALL be appended to this trap object ID, as a BER binary OID suffix. This trap OID qualifier allows device management/monitoring applications to limit the alerts they receive to ones generated by device details of interest.

A 'sparse' table containing device detail information for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790). Usage: UNLIKE the 'xcmGenOptionTable' in the XCMI General MIB (which is a unique exception), this table of 'dictionary-based' device details is used with DIRECT create/update operations.

A 'sparse' entry containing device detail information for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790). Usage: An entry in this table MAY be used to store specialized information for a device, such as 'lifetime' information for a CRU ('customer replaceable unit'), eg, a paper tray feed head.

The type of the device detail information specified in this conceptual row in the 'xcmHrDevDetailTable'.

A unique value used by this host system to identify this conceptual row in the 'xcmHrDevDetailTable', OR a common value shared across a set of related conceptual rows (with different values of 'xcmHrDevDetailType'. Usage: For device detail types which are single-valued, this index SHALL be used to correlate related single-valued details. Usage: For device detail types which are multi-valued, this index SHALL be used to enumerate lists of multi-valued details.

This object manages the row status of this conceptual row in in the 'xcmHrDevDetailTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevDetailRowStatus' row status object; and SHALL clear the 'xcmHrDevDetailGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevDetailRowStatus' row status object; and SHALL set the 'xcmHrDevDetailGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

The value unit class of the detail information specified in this conceptual row in the 'xcmHrDevDetailTable'. Usage: Used to select a textual convention for specifying the value unit of this device detail. Usage: The 'xcmHrDevDetail[UnitClass|Class]' objects are used to specify the value syntax AND the value unit of the 'xcmHrDevDetail[Integer|OID|String]' value objects.

The value unit of the detail information specified in this conceptual row in the 'xcmHrDevDetailTable'. Usage: Used to select an enumerated choice from a textual convention to specify the value unit of this device detail. Usage: The 'xcmHrDevDetail[UnitClass|Class]' objects are used to specify the value syntax AND the value unit of the 'xcmHrDevDetail[Integer|OID|String]' value objects.

A device detail value integer, used by system administrators and end users to specify the current value for a device detail with a base value syntax of 'INTEGER'.

A device detail value OID (object identifier), used by system administrators and end users to specify the current value for a device detail with a base value syntax of 'OBJECT IDENTIFIER'.

A device detail value string, used by system administrators and end users to specify the current value for a device detail with a base value syntax of 'OCTET STRING'. Usage: This object is of type 'XcmFixedLocaleDisplayString'. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object.

This object is used to provide a description of the detail. It is NOT expected to be parsed by the management application.

A 'sparse' table containing storage info objects for 'logical' or 'physical' storage elements on this host system, augmenting the basic entries in the 'hrStorageTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing storage info objects for a 'logical' or 'physical' storage element on this host system, augmenting a basic entry in the 'hrStorageTable' of the IETF Host Resources MIB (RFC 2790).

This object manages the row status of this conceptual row in the 'xcmHrStorageTable' and ALSO manages the row status of the associated conceptual row in the 'hrStorageTable' of the IETF Host Resources MIB (RFC 2790). Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrStorageRowStatus' row status object; and SHALL clear the 'xcmHrStorageGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrStorageRowStatus' row status object; and SHALL set the 'xcmHrStorageGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

An extended storage type (or storage 'realization'), used by system administrators and end users of this storage. Usage: The use of either 'other' or 'unknown' is uninformative and SHOULD be avoided by conforming implementations.

A storage status, used by system administrators and end users of this storage (here, read 'state' for 'status'). Usage: Conforming implementations SHALL NOT 'bubble up' status from 'physical' storage to associated 'logical' storage. All storage SHALL report its own status ONLY.

The value of 'hrDeviceIndex' corresponding to the product associated conceptual row in the 'hrDeviceTable' representing the product (container) device (eg, of type 'hrDevicePrinter'), which uses this storage.

The value of 'hrDeviceIndex' corresponding to the platform associated conceptual row in the 'hrDeviceTable' representing the CPU device (of type 'hrDeviceProcessor'), which manages this storage.

The value of 'hrDeviceIndex' corresponding to the paging associated conceptual row in the 'hrDeviceTable' representing the paging device (usually of type 'hrDeviceDiskStorage'), which provides secondary storage for swapping of this storage.

The value of 'hrDeviceIndex' corresponding to the matching associated conceptual row in the 'hrDeviceTable' representing the matching device (eg, of type 'hrDeviceDiskStorage'), which corresponds to this storage.

The value of 'hrSWRunIndex' corresponding to the superior associated conceptual row in the 'hrSWRunTable' representing the running software which manages this storage.

The value of 'hrSWInstalledIndex' corresponding to the superior associated conceptual row in the 'hrSWInstalledTable' representing the installed software which manages this storage.

The value of 'hrStorageIndex' corresponding to: a) the next associated row in the 'hrStorageTable'; or b) zero if this is the last associated conceptual row in a given set; or c) zero if this conceptual row is NOT part of a set.

The value of 'hrStorageIndex' corresponding to: a) the previous associated row in the 'hrStorageTable'; or b) zero if this is the first associated conceptual row in a given set; or c) zero if this conceptual row is NOT part of a set.

The value of 'hrStorageIndex' corresponding to the directly associated conceptual row in the 'hrStorageTable' representing: a) the first underlying 'physical' storage (if any), if this row has 'xcmHrStorageRealization' of 'logical...'; or b) the first subordinate 'physical' storage (if any), if this row has 'xcmHrStorageRealization' of 'physical...'; or c) zero if there is no underlying or subordinate 'physical' storage associated with this row (ie, this storage).

A 'sparse' table containing storage detail information for 'logical' or 'physical' storage elements on this host system, augmenting a basic entry in the 'hrStorageTable' of the IETF Host Resources MIB (RFC 2790). Usage: UNLIKE the 'xcmGenOptionTable' in the XCMI General MIB (which is a unique exception), this table of 'dictionary-based' storage details is used with DIRECT create/update operations.

A 'sparse' entry containing storage detail information for a 'logical' or 'physical' storage element on this host system, augmenting a basic entry in the 'hrStorageTable' of the IETF Host Resources MIB (RFC 2790).

The type of the storage detail information specified in this conceptual row in the 'xcmHrStorageDetailTable'.

A unique value used by this host system to identify this conceptual row in the 'xcmHrStorageDetailTable', OR a common value shared across a set of related conceptual rows (with different values of 'xcmHrStorageDetailType'. Usage: For storage detail types which are single-valued, this index SHALL be used to correlate related single-valued details. Usage: For storage detail types which are multi-valued, this index SHALL be used to enumerate lists of multi-valued details.

This object manages the row status of this conceptual row in in the 'xcmHrStorageDetailTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrStorageDetailRowStatus' row status object; and SHALL clear the 'xcmHrStorageDetailGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrStorageDetailRowStatus' row status object; and SHALL set the 'xcmHrStorageDetailGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

The value unit class of the detail information specified in this conceptual row in the 'xcmHrStorageDetailTable'. Usage: Used to select a textual convention for specifying the value unit of this storage detail. Usage: The 'xcmHrStorageDetail[UnitClass|Class]' objects are used to specify the value syntax AND the value unit of the 'xcmHrStorageDetail[Integer|OID|String]' value objects.

The value unit of the detail information specified in this conceptual row in the 'xcmHrStorageDetailTable'. Usage: Used to select an enumerated choice from a textual convention to specify the value unit of this storage detail. Usage: The 'xcmHrStorageDetail[UnitClass|Class]' objects are used to specify the value syntax AND the value unit of the 'xcmHrStorageDetail[Integer|OID|String]' value objects.

A storage detail value integer, used by system administrators and end users to specify the current value for a storage detail with a base value syntax of 'INTEGER'.

A storage detail value OID (object identifier), used by system administrators and end users to specify the current value for a storage detail with a base value syntax of 'OBJECT IDENTIFIER'.

A storage detail value string, used by system administrators and end users to specify the current value for a storage detail with a base value syntax of 'OCTET STRING'. Usage: This object is of type 'XcmFixedLocaleDisplayString'. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information stored in this string object.

A 'sparse' table containing cover and/or interlock info for installed and (possibly) active devices on this host system, augmenting the basic entries in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A 'sparse' entry containing cover and/or interlock info for an installed and (possibly) active device on this host system, augmenting a basic entry in the 'hrDeviceTable' of the IETF Host Resources MIB (RFC 2790).

A unique value used by this host system to identify this conceptual row in the 'xcmHrDevCoverTable'.

This object manages the row status of this conceptual row in the 'xcmHrDevCoverTable'. Usage: Conforming implementations which support static rows SHALL support 'active' and 'notInService' writes to this 'xcmHrDevCoverRowStatus' row status object; and SHALL clear the 'xcmHrDevCoverGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations which support dynamic rows SHALL support 'createAndGo' and 'destroy' writes to this 'xcmHrDevCoverRowStatus' row status object; and SHALL set the 'xcmHrDevCoverGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations need NOT support dynamic row creation (via 'createAndGo(4)') nor dynamic row deletion (via 'destroy(6)'). Usage: See section 3.4 'Secure Modes of Operation' and section 3.5 'Secure SNMP Get/Set Requests' in XCMI Security TC, for details of secure modes of access to this row status object.

Human-readable name of this device cover or interlock specified in this conceptual row in the 'xcmHrDevCoverTable'. Usage: This name SHALL be locally unambiguous (if specified) on this managed host system and SHALL be the one normally used in a CLI/GUI/API for identification of this device cover or interlock (eg, 'Cover1'). Usage: The the Printer MIB combines the name of a device cover or device interlock with the description, in one object - 'xcmHrDevCover[Name|Description]' add clarity.

Human-readable description of this device cover or interlock specified in this conceptual row in the 'xcmHrDevCoverTable'. Usage: This description MAY contain the manufacturer's name, the color, the physical location, etc, of this device cover or interlock (eg, 'Top front blue cover'). Usage: The the Printer MIB combines the name of a device cover or device interlock with the description, in one object - 'xcmHrDevCover[Name|Description]' add clarity.

The type of the device cover or interlock specified in this conceptual row in the 'xcmHrDevCoverTable'. * 'true' - this is a device cover conceptual row; * 'false' - this is a device interlock conceptual row. Usage: The the Printer MIB combines the identity of cover versus interlock with the status of open versus closed, in one object - 'xcmHrDevCover[TypeCover|StatusOpen]' add clarity.

The status of the device cover or interlock specified in this conceptual row in the 'xcmHrDevCoverTable'. * 'true' - this cover/interlock is currently open; * 'false' - this cover/interlock is currently closed. Usage: The the Printer MIB combines the choice of cover versus interlock with the status of open versus closed, in one object - 'xcmHrDevCover[TypeCover|StatusOpen]' add clarity.

The value of the enterprise-specific OID in an SNMPv1 trap sent whenever a device alert row transitions to 'active' row status or (optionally) transitions to 'notInService' row status in 'xcmHrDevAlertTable'. See SNMPv2 trap definition 'xcmHrDevAlertV2Event' below for 'special semantics'.

This trap is sent whenever a device alert row transitions to 'active' row status or (optionally) transitions to 'notInService' row status in 'xcmHrDevAlertTable'. This trap is sent when requested by a prior subscription. Note: The variable-bindings of this trap have been chosen to specify a complete device alert event while keeping trap messages reasonably concise (generally a few hundred octets at most). This notification has the following special semantics: o The device's 'hrDeviceIndex' field value SHALL be appended to this trap object ID, as a BER binary OID suffix. This trap OID qualifier allows device management/monitoring applications to limit the alerts they receive to ones generated by devices of interest. Systems MAY add other variable-bindings from any MIB.

A table of the device alerts which have been generated and recorded on this host system. Certain devices can be associated with specific alert tables defined industry wide for the specific device. This general alert table is designed to work with these other alert tables. At this time, the only device specific alert table is prtAlertTable in the printer MIB. See xcmHrDevAlertCodeInteger and xcmHrDevAlertDevAlertIndex for connections to the device specific alert table. Usage: Conforming implementations SHALL ensure that this table contains (up to) a product-specific number of the most 'recent' device alerts on this host system. Usage: When an event occurs that should be reported through the Alert table, the implementation SHALL create an alert for each device impacted by the event. This SHOULD include all logical devices containing the impacted device. All such alerts SHALL have the same index 'xcmHrDevAlertIndex.' Usage: If the hrDeviceIndex is an hrDevicePrinter, then the product SHALL also generate an alert in the IETF 'prtAlertTable.' The index 'prtAlertIndex' for the associated printer alert table entry SHALL be returned in 'xcmHrDevAlertDevAlertIndex' for the 'hrDevicePrinter' index. Management tools can use the value of 'xcmHrDevAlertDevAlertIndex' to associate printer alerts with alerts in this table. Usage: Conforming implementations which also implement the System Fault group SHALL record in 'xcmHrSystemFaultTable' each persistent system fault when it occurs and is recorded in 'xcmHrDevAlertTable'. Usage: Conforming implementations MAY 'age' older entries out of 'xcmHrDevAlertTable' based on algorithms which depend on the age of the entry and the particular alert. When the number of alerts in the table exceeds the product-specific maximum number of alerts, the oldest non-critical alert SHALL be removed. If there are no non-critical alerts, then the oldest critical alert SHALL be removed.

An entry for a device alert which has been generated and recorded on this host system.

A unique value used by this host system to identify this conceptual row in the 'xcmHrDevAlertTable'. Usage: Conforming implementations SHALL NOT 'reuse' values of 'xcmHrDevAlertIndex' until its' 32-bit value wraps. Even in the case of eventual wrap, the entries SHALL be strictly sequenced by the associated value of 'xcmHrDevAlertDateAndTime.' Usage: When an event causes an alert on several devices, all such alerts SHALL have the same 'xcmHrDevAlertIndex.' Usage: Conforming implementations are strongly encouraged to preserve the last used value of 'xcmHrDevAlertIndex' across system power cycles.

This object is used to create (by management agent) and delete (by management station and/or management agent) individual conceptual rows in the 'xcmHrDevAlertTable'. Usage: Management stations can not create rows in the alert table. Conforming implementations SHALL support 'active' and 'notInService' writes to this 'xcmHrDevAlertRowStatus' row status object; and SHALL clear the 'xcmHrDevAlertGroup' bit in 'xcmHrGeneralCreateSupport' in the 'xcmHrGeneralTable'. Usage: Conforming implementations MAY support dynamic row deletion via 'destroy(6)'. This allows management stations to delete any any obsolete unary non-critical alerts.

Device-specific severity level for the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'. Usage: Conforming management agents SHALL set one bit (specific severity level) or zero bits (no severity level reported) in this object.

Device-specific training level for the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'. Usage: Conforming management agents SHALL set one bit (specific training level) or zero bits (no training level reported) in this object.

Device-specific code for the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'. Usage: Conforming implementations SHALL use the values specified in any device-specific alert table. For devices of type 'hrDevicePrinter', this value SHALL be the same as the 'PrtAlertCodeTC' returned in 'prtAlertCode.' The value of 0 means that no code has been assigned to this alert. This value is intended for internal use by management applications rather than for human display. It should not be confused with 'xcmHrDevAlertCodeString;' the two values are generally NOT the same and there is no assumed mapping from one to the other. All values in the range 1..99999 are reserved for definition within a device specific MIB. Values 100000..199999 will be defined within this MIB in future versions. Individual products may define values 200000 and larger.

Product-specific 'reportable alert code' string for the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'. This is a product-specific value used in documentation when describing this alert. Usage: This value is intended for human display, and typically contains an alphanumeric code or keyword phrase. It should not be confused with 'xcmHrDevAlertCodeInteger;' the two values are generally NOT the same and there is no assumed mapping from one to the other. Usage: Often this string is not translated since it has no specific meaning.

Human-readable alert description for the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'. Usage: This is a human-readable string, not intended for machine parsing. Management stations SHOULD obtain the alert-specific fault code and severity level from the 'xcmHrDevAlertCodeString' and 'xcmHrDevAlertSeverityLevel' and the current status from 'hrDeviceStatus' objects rather than trying to interpret this string. Implementators are strongly encouraged to include in this description: - a description of the problem, - a description of the corrective action or a statement that no corrective action is required, - a description of the impact on device operations. Implementors SHOULD NOT include in this description a statement of the current operating state of the device, since the device state may be changed by some other event unrelated to this alert, making any such statement invalid. A statement such as 'Device operation may continue' or 'This problem must be corrected before the device can resume operation' is acceptable. Usage: Conforming implementations SHALL provide BOTH detailed 'xcmHrDevAlertDescription' AND terse 'xcmHrDevAlertTitle' descriptions for each critical alert and for each alert which requires human intervention. Implementations MAY provide the same text for both strings. Usage: Implementations SHALL provide localized translations of this string via the 'xcmGenMessageTextTable.' Usage: For devices of type 'hrDevicePrinter', this SHOULD be the same description provided in 'prtAlertDescription' in the IETF Printer MIB alert table. Implementations MAY choose to make these descriptions different in order to differentiate between IETF-only and XCMI-aware management applications.

An (optional) unambiguous system object reference (which MAY include an object instance qualifier suffix), used to specify supplemental information for this device alert. Usage: Since this system object reference is specified as an ASN.1 object identifier, it MAY be taken from any IETF, Xerox, third-party, or product-specific MIB, or it MAY simply be any IETF SMIv2-style 'autonomous type'. Usage: If 'xcmHrDevAlertReferenceIndex' is greater than 0, then it is an index into a table referenced by 'xcmHrDevAlertReferenceOID.' Usage: Devices of type 'hrDevicePrinter' SHALL set 'xcmHrDevAlertReferenceOID' to the OID of the table or group referred to by 'prtAlertGroup' in the IETF printer alert table. (This may be a table or group in the host resources MIB, printer MIB, finisher MIB, or other MIB as enumerated by 'PrtAlertGroupTC'.) Note: Given the flexibility this object provides, the information is only valuable to the Management Station if the OID is a well known OID.

The date and time stamp for the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'.

A terse description of the problem or corrective action associated with the device alert which is recorded in this conceptual row in the 'xcmHrDevAlertTable'. Usage: This is a human-readable string, not intended for machine parsing. This message should be constructed for display in a navigation tree or other contexts where the management station's user interface may have strict limits on message length and complexity. The message should identify the general type and area of the alert but omit most details in the interest of brevity, e.g. 'tray empty' or 'replace toner' but not 'load A4 Transparency in top tray' or 'replace cyan toner cartridge.' Implementations are strongly encouraged to supply more detailed information in 'xcmHrDevAlertDescription' but may simply supply the same text for both strings. Usage: Conforming implementations SHALL provide both detailed 'xcmHrDevAlertDescription' and terse 'xcmHrDevAlertTitle' descriptions for each critical alert and for each alert which requires human intervention. Usage: Implementations SHALL provide localized translations of this string via the 'xcmGenMessageTextTable.'

A key into a help reference. This key is intended for machine usage as either a key into a database or as part of a path name to additional information. Usage: This string may be used by a management station to construct the complete URL or pathname of a file which may be stored on the management station, the managed device, a customer's server or a Xerox web server. The mechanism by which the URL or pathname should be constructed, including any requested localization, is product- and application- dependent. For example, if the device returns a string containing two path components /, a host-based management application might construct either the pathname '//.' or '///' depending on how the author wanted to organize and distribute help files for various products and locales. A web-based application with knowledge of the managed device's embedded web server might be able to construct the URL 'http:///alert-info//' and request a specific localization via the HTTP 'accept- language' and 'accept-charset' headers. Usage: Implementors SHALL use only the US-ASCII alphanumeric characters 'A'-'Z', 'a'-'z', '0'-'9' and the punctuation marks underscore ('_'), hyphen ('-'), and forward slash ('/'). The first and last characters must be alphanumeric. Implementors should note that some hosts distinguish between upper- and lower-case letters in pathnames and others don't. Therefore, different help paths should differ by more than just letter case, and product documentation MUST accurately reflect the strings returned in 'xcmHrDevAlertHelpReference', including letter case. Rationale: Limiting the character set in this way ensures that the string can be used to construct a valid pathname or URL on the widest variety of host systems. Note that the file name is not localized (although the contents may be) and not generally displayed for users, so there is little need to support characters outside of this basic US-ASCII set.

An (optional) index into a system table used to specify supplemental information for this device alert. Usage: When xcmHrDevAlertReferenceOID is a table, xcmHrDevAlertReferenceIndex can be an index into that table. Note: If the ReferenceOID table has multiple indices, the management table must recognize the table and must know which index is given by this ReferenceIndex. Usage: Use -1 if no index is required.

A product-specific refinement of the source of an alert. The value 'unknown(-2)' indicates that the device has no additional information to provide.

An index into a device-specific alert table. When 'hrDeviceIndex' is of type 'hrDevicePrinter', then this field SHALL be the value of 'prtAlertIndex' for the same alert.

A sorting hint for user interfaces displaying device alerts. Usage: this field allows a device to suggest, for instance, that the 'replace fuser' alert should be displayed before the 'close door' alert in a list or navigation tree. Alert priorities are ordinal numbers, with 1 indicating the highest priority for display. A value of zero means 'no priority hint available'.

The value of 'xcmHrDevAlertIndex' for the most recently-added alert (critical or non-critical) in the alert table. This value only reflects the most recently added alert; if the alert is subsequently cleared, the value of 'xcmHrDevAlertAllEvents' SHALL NOT be changed as a result. Compliant implementations SHALL report zero if no alerts have been added to the table. A management tool may use the fact that this value has not changed to avoid checking for new alerts. Note that the value of this object will 'wrap' when the first alert is added to the table after 'xcmHrDevAlertIndex' has reached 2**32 - 1 and 'wrapped' to 1.

The value of 'xcmHrDevAlertIndex' for the most recently-added critical alert in the alert table. This value only reflects the most recently added alert; if the alert is subsequently cleared, the value of 'xcmHrDevAlertLastCriticalAlertIndex' SHALL NOT be changed as a result. Compliant implementations SHALL report zero if no critical alerts have been added to the table. A management tool may use the fact that this value has not changed to avoid checking for new critical alerts. Note that the value of this object will 'wrap' when the first critical alert is added to the table after 'xcmHrDevAlertIndex' has reached 2**32 - 1 and 'wrapped' to 1.

A table containing system local console screen (page) info for an installed local user interface console on this host system.

An entry containing system local console screen (page) info for an installed local user interface console on this host system. Usage: Conforming management agents SHOULD report local console info via 'hrDeviceIndex' for 'hrDevicePrinter' - consistent with 'prtConsoleDisplayBufferTable' in the Printer MIB - or 'hrDeviceIndex' for 'xcmHrDeviceHostSystem' in XCMI HRX TC.

A unique value used by this host system to identify this conceptual row in the 'xcmHrConsoleScreenTable'.

Human-readable name of this local console screen (page), used by system administrators and end users to identify this screen for systems management. Usage: Conforming management agents SHOULD NOT report the same value of 'xcmHrConsoleScreenName' for different screens (pages). Screens (pages) are always uniquely labelled by their indices of 'xcmHrDeviceIndex' and 'xcmHrConsoleScreenIndex'.

Human-readable description of this local console screen.

Parent console screen index associated with this local console screen (page), or zero (if none). Usage: Value of 'xcmHrConsoleScreenIndex' for parent screen. This object MAY be used to report tree or forest relationships between local console screens. Trees have a single root screen. Forests have two or more root screens (w/ no parent screen).

The display priority of this local console screen (page). Usage: The display priority of this screen (page), where '0' is unspecified (default), '1' is lowest, and '100' is highest. When two screens (pages) have equal priority, the first (lowest) value of 'xcmHrConsoleScreenIndex' (lexicographical order) SHALL have the highest display priority.

Number of tabs (buttons) on this local console screen (page). Usage: Conforming management agents SHALL report values of 'xcmHrConsoleTabIndex' that are less than or equal to the value of 'xcmHrConsoleScreenTabCount' for the SAME value of 'xcmHrConsoleScreenIndex' (enclosing screen).

A table containing system local console tab (button) info for an installed local user interface console on this host system.

An entry containing system local console tab (button) info for an installed local user interface console on this host system. Usage: Conforming management agents SHOULD report local console info via 'hrDeviceIndex' for 'hrDevicePrinter' - consistent with 'prtConsoleDisplayBufferTable' in the Printer MIB - or 'hrDeviceIndex' for 'xcmHrDeviceHostSystem' in XCMI HRX TC.

A unique value used by this host system to identify this conceptual row in the 'xcmHrConsoleTabTable'.

Human-readable name of this local console tab (button), within the enclosing local console screen (page), used by system administrators and end users to identify this tab for systems management. Usage: Conforming management agents MAY report the same value of 'xcmHrConsoleTabName' for different tabs (buttons). Tabs (buttons) are always uniquely labelled by their indices of 'xcmHrDeviceIndex', 'xcmHrConsoleScreenIndex', and 'xcmHrConsoleTabIndex'.

Human-readable description of this local console tab (button), within the enclosing local console screen (page).

New local console screen selected by this local console tab (button). Usage: Value of 'xcmHrConsoleScreenIndex' for the new screen.

The display priority of this local console tab (button) within the enclosing local console screen (page). Usage: The display priority of this tab (button), where '0' is unspecified (default), '1' is lowest, and '100' is highest. When two tabs (buttons) have equal priority, the first (lowest) value of 'xcmHrConsoleTabIndex' (lexicographical order), for the SAME value of 'xcmHrConsoleScreenIndex' (enclosing screen), SHALL have the highest display priority.

A table containing information on all supplies for the managed system. Usage: Rows of the table are created by the agent. Certain values in the rows can be set by a management tool.

See xcmHrSuppliesTable

A unique value used by the agent to identify this supply. Although these values may change due to a major reconfiguration of the device (e.g. the addition of new finishing module to the printer), values SHOULD remain stable across successive printer power cycles.

A system object reference (which SHALL include an object instance qualifier suffix), used to specify an object in another table related to this supply. Usage: If the supply also appears in the prtMarkerSuppliesTable, then this referenceOID SHALL be the OID for the prtMarkerSuppliesDescription for this supply. Usage: If the supply also appears in the finSupplyTable, then this referenceOID SHALL be the OID for the finSupplyDescription for this supply. Usage: If the supply also appears in some other table (such as a scanner supplies table), then this referenceOID SHALL be the OID for the description column for this supply if a description column exists. Otherwise it SHALL be the first column of the other table as the reference OID. Usage: If the supply does not appear in any other table, then this referenceOID SHALL be the OID for hrDeviceDescr for the physical device requiring or using this supply. Usage: If no physical device in the hrDeviceTable requires the supply, then the hrDeviceTable is not complete. Note: Given the flexibility this object provides, the information is only valuable to the Management Station if the OID is a well-known OID. Note: This object has no default value since it must be filled in.

An indication of the type of device. Use device type OIDs.

This object describes how this type is replaced. Values range from 'it never breaks' to 'untrained user'. A value of 'Unknown(2)' should never be used. Use the least restrictive type if it is not clear. For example, if a part is usually replaced by service, but a customer can order it and replace it on their own, then the supply would be 'CustomerReplaceable(4)'.

A description of this supply. This name MUST match the name of the supply as it will be exposed on www.xerox.com, within the printer's web UI, within the printer's local UI and within all configuration pages that can be generated by the printer.

The part number used to order this supply. This part number may depend on the location of the machine. If no part number is associated with this supply, then the value will be blank (null).

A 'sparse' table containing detail information for rows of other SNMP tables' Usage: Rows of the table are created by the agent. Certain values in the rows can be set by a management tool. Usage: OSI ASN.1 encoding rules (ISO 8825) and IETF SNMP rules REQUIRE that when object identifiers (OIDs) are used as table indices, the first arc (sub- identifier) of each object identifier MUST be preceded by the count of arcs (sub- identifiers) in the object identifier (see 'Mapping of the INDEX clause' in SNMPv2-SMI, RFC 2578), unless the index is rightmost (low-order) and specified with the IMPLIED keyword. Thus, the xcmHrDetailTableIndex index of xcmHrDetailEntry MUST be preceded by an arcs count in SNMP request/response PDUs. So, if we wanted the Total Black Impressions using the third xcmHrSupplies row (lets assume that is the toner cartridge) we would do an SNMP Get on the object 1.3.6.1.4.1.253.8.51.1.3.1.7.1.1.3.20.34 Because 1.3.6.1.4.1.253.8.51.1.3.1.7 is the OID of xcmHrDetailValueInteger. 1 is the enumeration for the xcmHrSuppliesTable. 3 is the index into the xcmHrSupplies table for this cartridge (and there is 1 arcs there). 20 is the detail type for lifetime usage. And 34 is the index from table 22 of the XMIG for 'Total Black Impressions'.

See xcmHrDetailTable

This object is used to identify the table that this detail is qualifying. Usage: To provide additional information on supplies that are defined in the xcmHrSuppliesTable, prtMarkerSuppliesTable or finSupplyTable.

This object is used to provide the index of the specific row in the table referenced by xcmHrDetailTableRef. Usage: To identify a supply in the xcmHrSuppliesTable, use the single octet xcmHrSuppliesIndex. Usage: To identify a supply in the prtMarkerSuppliesTable, use the single octet prtMarkerSuppliesIndex. Usage: To identify a supply in the finSupplyTable, use the single octet finSupplyIndex.

The type of the detail information specified in this row of the table.

This object supports details which have multiple values and can also be used to correlate related values of different types. Usage: For distinct detail types which are related, this index SHALL be equal for related detail values. Usage: For detail types which are multi-valued, this index SHALL be used to enumerate the list of details.

The value/unit class of the detail information specified in this row of the table. Usage: Used to select a textual convention for specifying the value unit of this device detail. Usage: Also used to specify which of xcmHrDetailValue[Integer|OID|String] are used to contain the detail value. Usage: Typically the value of xcmHrDetailUnitClass is listed explicitly in the description of the XcmHrDevDetailType enumeration. In that case, the agent SHALL populate this object with the listed enumeration and a management tool does not have to check this object to determine the unit class.

This object makes explicit the units in which this detail value is being specified. Usage: Used to select an enumerated choice from a textual convention to specify the value unit of this device detail. The specific textual convention is identified by xcmHrDetailUnitClass.

The current value for a device detail with a base value syntax 'INTEGER'.

The current value for a device detail with a base value syntax 'OID'.

The current value for a device detail with a base value syntax 'STRING'. This object is also used to provide secondary information when the base value syntax is 'INTEGER' or 'OID'. Typically this is a string version of the value of the detail.

This object is used to provide a description of the detail.

A table containing system local console information for an installed local user interface console on this host system.

An entry containing system local console information for an installed local user interface console on this host system. Usage: Conforming management agents SHOULD report local console info via 'hrDeviceIndex' for 'hrDevicePrinter' - consistent with 'prtConsoleDisplayBufferTable' in the Printer MIB - or 'hrDeviceIndex' for 'xcmHrDeviceHostSystem' in XCMI HRX TC.

A unique value used by this host system to identify this conceptual row in the 'xcmHrConsoleTable'.

The default service shown on the console user interface. This is used to change the meaning of the Green Button on the front panel of many devices.

The console brightness level. Often this a number from 1 to 10 where 1 is dimmest and 10 is brightest.

The console contrast level. Often this a number from 1 to 10 where 1 is least contrast and 10 is most contrast.

Turns On/off control panel accessibility mode. When On, value=true, the console does not timeout and key repeating is off. When Off, value=false, the console panel times out after specified period of no activity and key repeating is on.

The automatic clear timeout for the console. Often this a numbe 0 to 120 where 0 is console never times out and 120 means the console times out after 120 seconds of no activity.

The insertion timeout for console prompts. Often this a number 0, 60 or -1 where 0 is console never prompts, 60 means the console prompts the user for 60 seconds than stops and -1 means the console prompt is displayed for an infinite amount of time.

The insertion timeout for console prompts for tray 1 events. Often this a number 0, 60 or -1 where 0 is console never prompts, 60 means the console prompts the user for 60 seconds than stops and -1 means the console prompt is displayed for an infinite amount of time.

The insertion timeout in seconds for console prompts for trays 2 through n events. Often this a number 0, 60 or -1 where 0 is console never prompts, 60 means the console prompts the user for 1 minute than stops and -1 means the console prompt is displayed for an infinite amount of time.

The amount of time in minutes the system waits for before using the default media source for the device.

The console sound volume control. This is often used to control how loud the fax modem telephone line sound is. This is often a number 0 through 10 where 0 is console sounds are off, 1 is the lowest volume and 10 is the highest volume.

The console sound duration. This is often used to control how long the sound will last when the fax modem telephone line soun is on. This is often a number 1 through 255 where 1 means the console sounds are on for 1 second and 255 means the console sounds are on for 255 seconds.

This object provides a name of a parameter that can be returned and modified by SNMP. Usage: Conforming management agents SHALL 'reject' any SNMP Set-request to xcmHrGenericParamName if the parameter name is invalid, with 'bad Value' error. Usage: Conforming management stations can set 'xcmHrGenericParamName', i.e. the parameter name and 'xcmHrGenericParamValue', i.e. the parameter value SIMULTANEOUSLY in the same SNMP Set-Request PDU using a BULK-SET request. The order in the BULK-SET must be 'xcmHrGenericParamName', followed by 'xcmHrGenericParamValue'

This object provides a value for a parameter that can be returned and modified by SNMP. To get a parameter value the manager will need to SET 'xcmHrGenericParamName' to inform the agent what parameter value is desired. Then a GET request on this object will return the value for the parameter requested. Usage: Conformant implementations MUST encrypt passwords, keys, and other security information in SET requests made to this object. Usage: Conformant implementations MUST NOT return passwords, keys, and other security information in response to GET requests made to this object. Usage: Conforming management stations can set 'xcmHrGenericParamValue', i.e. the parameter value and 'xcmHrGenericParamName', i.e. the parameter name SIMULTANEOUSLY in the same SNMP Set-Request PDU using a BULK-SET request. The order in the BULK-SET must be 'xcmHrGenericParamName', followed by 'xcmHrGenericParamValue'