Internet-Draft Ryan Moats draft-moats-dmtf-physical-ldap-01.txt Gerald Maziarski Expires in six months AT&T John Strassner cisco Systems December 1999 LDAP Schema for the DMTF Physical CIM v2.2 Model Filename: draft-moats-dmtf-physical-ldap-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This draft presents a LDAP schema for the DMTF CIM Physical model version 2.2 [4]. 1. Introduction This draft presents a LDAPv3 [1,2] schema for the DMTF CIM Physical model. Associations are mapped using a combination of auxiliary classes and DIT structure rules. Where auxiliary classes are used, name form and DIT content rules are specified. This document is not a product of the DMTF, and represents the view of the authors. Expires 6/30/00 [Page 1]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 2. LDAP Mapping Considerations There are several special considerations in mapping the physical model from CIM to LDAP. They are discussed in this section. 2.1 Modifications to cimAssociationInstance The core mapping [5] defined cimAssociationInstance as a helper class. To support the auxiliary classes, the following classes should be added to cimAssociationInstance's content rule: cim22PhysicalElementLocationAuxClass cim22ElementCapacityAuxClass cim22ParticipatesInSetAuxClass cim22ContainerAuxClass cim22ChassisInRackAuxClass cim22PackageInChassisAuxClass cim22DockedAuxClass cim22CardOnCardAuxClass cim22DeviceServicesLocationAuxClass cim22PackagedComponentAuxClass cim22MemoryOnCardAuxClass cim22MemoryWithMediaAuxClass cim22PhysicalMediaInLocationAuxClass cim22ElementsLinkedAuxClass cim22ConnectedToAuxClass cim22SlotInSlotAuxClass cim22AdjacentSlotsAuxClass cim22PackageInConnectorAuxClass cim22PackageInSlotAuxClass cim22CardInSlotAuxClass cim22LinkHasConnectorAuxClass cim22ConnectorOnPackageAuxClass cim22AdapterActiveConnectionAuxClass cim22ComputerSystemPackageAuxClass cim22LibraryPackageAuxClass cim22PackageCoolingAuxClass cim22PackageTempSensorAuxClass cim22PackageAlarmAuxClass Also, the following structure rules defined here need to be added to the structure rule for cimAssociationInstance: <sr12>, <sr13>, <sr14>, <sr15>, <sr16>, <sr17>, <sr18>, <sr19>, and <sr20>. 2.2 cimServicePhilosophyInstance The class cimPhysicalFrame defines two linked indexed arrays: ServicePhilosophy and ServiceDescription. In the LDAP mapping, these Expires 6/30/00 [Page 2]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 are replaced with separate instances of cimServicePhilosophyInstance, DIT contained by cimPhysicalFrame. ( <oid-at98> NAME 'cimServicePhilosophy' DESC 'ServicePhilosophy is an enumerated, integer value that indicates whether the Frame is serviced from the top (value=2), front (3), back (4) or side (5), whether it has sliding trays (6) or removable sides (7), and/or whether the Frame is moveable (8), for example, having rollers.' SYNTAX integer SINGLE-VALUE ) ( <oid-at99> NAME 'cimServiceDescriptions'n DESC 'A free-form strings providing more detailed explanations for this entries. SYNTAX string SINGLE-VALUE ) ( <oid-oc92> NAME 'cimServicePhilosophyInstance' DESC 'helper class to tie ServicePhilosophy and ServiceDescriptions in PhysicalFrame together' SUP top MUST (arrayIndex) MAY (cimServicePhilosophy $ cimServiceDescription) ) ( <oid-nf21> NAME 'cimServicePhilosophyInstanceNameForm' OC cimServicePhilosophyInstance MUST (arrayIndex) ) ( <sr21> NAME 'cimServicePhilosophyInstanceStructureRule' FORM cimServicePhilosophyInstanceNameForm SUP <sr17> ) 2.3 cimChassisTypeInstance The class cimChassis defines two linked indexed arrays: ChassisTypes and TypeDescriptions. In the LDAP mapping, these are replaced with separate instances of cimChassisTypeInstance, DIT contained by cimChassis. ( <oid-at111> NAME 'cimChassisTypes' DESC 'An enumerated, integer value indicating the type of Chassis.' SYNTAX integer SINGLE-VALUE ) Expires 6/30/00 [Page 3]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-at112> NAME 'cimTypeDescriptions' DESC 'A free-form strings providing more information on the ChassisTypes array entries.' SYNTAX string SINGLE-VALUE ) ( <oid-oc93> NAME 'cimChassisTypeInstance' DESC 'helper class to tie ChassisType and TypeDescriptions in Chassis together' SUP top MUST (arrayIndex) MAY (cimChassisType $ cimTypeDescription) ) ( <oid-nf22> NAME 'cimChassisTypeInstanceNameForm' OC cimChassisTypeInstance MUST (arrayIndex) ) ( <sr22> NAME 'cimChassisTypeInstanceStructureRule' FORM cimChassisTypeInstanceNameForm SUP <sr18> ) 2.4 cimMediaTypesSupportedInstance The class cimStorageMediaLocation defines two linked indexed arrays: MediaTypesSupported and MediaSizesSupported. In the LDAP mapping, these are replaced with separate instances of cimMediaTypeSupportedInstance, DIT contained by cimStorageMediaLocation. ( <oid-at125> NAME 'cimMediaTypesSupported' DESC 'Certain StorageMediaLocations may only be able to accept a limited set of PhysicalMedia MediaTypes. This property defines the types of Media that are acceptable for placement in the Location. SYNTAX integer SINGLE-VALUE ) ( <oid-at126> NAME 'cimMediaSizesSupported' DESC 'The size (in inches) of the particular MediaTypes that may be placed in the Location.' SUP cim22Float32 SINGLE-VALUE ) ( <oid-oc94> NAME 'cimMediaTypesSupportedInstance' DESC 'helper class to tie MediaTypesSupported and Expires 6/30/00 [Page 4]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 MediaSizesSupported in StorageMediaLocation together' SUP top MUST (arrayIndex) MAY (cimMediaTypesSupported $ cimMediaSizesSupported) ) ( <oid-nf23> NAME 'cimMediaTypesSupportedInstanceNameForm' OC cimMediaTypesSupportedInstance MUST (arrayIndex) ) ( <sr23> NAME 'cimMediaTypesSupportedInstanceStructureRule' FORM cimMediaTypesSupportedInstanceNameForm SUP <sr19> ) 2.5 cimPhysicalLabelsInstance The class cimPhysicalMedia defines three linked indexed arrays: PhysicalLabels, LabelStates, and LabelFormats. In the LDAP mapping, these are replaced with separate instances of cimPhysicalLabelsInstance, DIT contained by cimPhysicalMedia. ( <oid-at143> NAME 'cimPhysicalLabels' DESC '"labels" on the PhysicalMedia. The format of the labels and their state (readable, unreadable, upside-down) are indicated in LabelFormats and LabelStates properties.' SYNTAX string SINGLE-VALUE ) ( <oid-at144> NAME 'cimLabelStates' DESC 'An enumerated integer describing the state of a label on a PhysicalMedia. The Label is listed in the PhysicalLabels property.' SYNTAX integer SINGLE-VALUE ) ( <oid-at145> NAME 'cimLabelFormats' DESC 'An enumerated integer describing the format of a label on a PhysicalMedia. The Labels is listed in the PhysicalLabels property.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc95> NAME 'cimPhysicalLabelsInstance' DESC 'helper class to tie PhysicalLabels, LabelStates, and LabelFormats in PhsyicalMedia together' Expires 6/30/00 [Page 5]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 SUP top MUST (arrayIndex) MAY (cimPhysicalLabels $ cimLabelStates $ cimLabelFormats) ) ( <oid-nf24> NAME 'cimPhysicalLabelsInstanceNameForm' OC cimPhysicalLabelsInstance MUST (arrayIndex) ) ( <sr24> NAME 'cimPhysicalLabelsInstanceStructureRule' FORM cimPhysicalLabelsInstanceNameForm SUP <sr20> ) 2.6 Floating point attributes: cimFloat32 and cimFloat64 Several attributes in this schema inherit from the attributes cimFloat32 and cimFloat64, defined in [6]. Interested readers are directed there for information about these attribute definition. 3. Class Definitions For efficiency in the LDAP representation, associations are specified as a combination of auxiliary classes and DIT structure rules. Attribute definitions for each class are presented with the object class. Other definitions are also provided when necessary. This approach minimizes the number of DN pointers stored in the schema, but some pointer dereferencing is necessary. While not explicitly stated in the definitions below, we assume that all attributes with DN support the matching rule defined in [3]. Attribute names for DN pointers also follow the convention that a single pointer's name ends in "Ref", while an array of pointers' name ends in "Refs". Note: all attribute, object class, and name form OIDs are place holders, and syntax OIDs in definitions have been replaced by names for clarity. There are some classes that aren't included in this mapping: Since MediaTransferDevice isn't included in the device model, DeviceServiceLocation isn't included here. MediaPhysicalStatInfo isn't included here because it is filled with nothing but counters. Without StorageExtents, the associations RealizesExtent, RealizesPExtent, RealizesDiskPartition, RealizesAggregatePExtent, and RealizesTapePartition do not make sense to include here. Finally, the PackageTempSensor association is not included because there are Expires 6/30/00 [Page 6]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 no TemperatureSensors in the schema. 3.1 cim22Location Locations are the position and address of a PhysicalElement. ( <oid-at76> NAME 'cimPhysicalPosition' DESC 'Position is a free-form string indicating the placement of PhysicalElement. It can specify slot information on a HostingBoard, mounting site in a Cabinet, or latitude and longitude information, for example, from a GPS. It is part of the key of the Location object.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at77> NAME 'cimAddress' DESC 'Address is a free-form string indicating a street, building or other type of address for the PhysicalElement's Location.' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-oc46> NAME 'cim22Location' DESC 'The Location class specifies the position and address of a PhysicalElement.' SUP top MUST (orderedCimModelPath $ cimName $ cimPhysicalPosition) MAY (cimAddress) ) ( <oid-nf12> NAME 'cim22LocationNameForm' OC cim22Location MUST (orderedCimModelPath) ) ( <sr12> NAME 'cim22LocationStructureRule' FORM cim22LocationNameForm ) The following content rule specifies the auxiliary classes that may be attached to cim22Location. ( <oid-oc46> NAME 'cim22LocationContentRule' DESC 'The auxiliary classes that may be attached to cim22Location' AUX (cim22PhysicalElementLocationAuxClass) ) Expires 6/30/00 [Page 7]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 3.2 cim22PhysicalElementLocationAuxClass This class associates a physical element with a cim22Location object. ( <oid-at78> NAME 'cimPhysicalLocationRef' DESC 'The PhysicalElement's Location.' SYNTAX DN ) ( <oid-oc47> NAME 'cim22PhysicalElementLocationAuxClass' DESC 'PhysicalElementLocation associates a PhysicalElement with a Location object for inventory or replacement purposes. Attribute cimElementRef points to cim22PhysicalElement and attribute cimPhysicalLocationRef points to cim22Location. ' SUP top AUXILIARY MAY (cimElementRef $ cimPhysicalLocationRef) ) 3.3 cim22PhysicalCapacity This class describes a physical element's requirements. ( <oid-oc48> NAME 'cim22PhysicalCapacity' DESC 'PhysicalCapacity is an abstract class describing a PhysicalElement's minimum/maximum requirements and ability to support different types of hardware. For example, minimum and maximum memory requirements can be modeled as a subclass of cim22PhysicalCapacity.' SUP top ABSTRACT MAY (cimName $ cimCaption $ cimDescription) ) 3.4 cim22ElementCapacityAuxClass This class associates a cim22PhysicalCapacity object with one or more cim22PhysicalElements. ( <oid-at79> NAME 'cimCapacityRef' DESC 'PhysicalCapacity describes the minimum and maximum requirements, and ability to support different types of hardware for a PhysicalElement.' SYNTAX DN ) ( <oid-oc49> NAME 'cim22ElementCapacityAuxClass' DESC 'ElementCapacity associates a PhysicalCapacity object with one or more PhysicalElements. It serves to associate a Expires 6/30/00 [Page 8]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 description of min/max hardware requirements or capabilities (stored as a kind of PhysicalCapacity), with the PhysicalElements being described. Attribute cimCapacityRef points to cim22PhysicalCapacity. Attribute cimElementRef points to cim22PhysicalElement.' SUP top AUXILIARY MAY (cimCapacityRef $ cimElementRef) ) 3.5 cim22MemoryCapacity Physical elements are limited in what memory can be installed. Instances of this class store information on what memory is currently installed. ( <oid-at80> NAME 'cimMemoryType' DESC 'The type of memory. This is a part of the object key. Values correspond to the list of possible memory types in the PhysicalMemory class.' SYNTAX integer SINGLE-VALUE ) ( <oid-at81> NAME 'cimMinimumMemoryCapacity' DESC 'Minimum amount of memory, in Kbytes, that is needed for the associated PhysicalElement to operate correctly. SYNTAX integer SINGLE-VALUE ) ( <oid-at82> NAME 'cimMaximumMemoryCapacity' DESC 'Maximum amount of memory, in Kbytes, that can be supported by the associated PhysicalElement.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc50> NAME 'cim22MemoryCapacity' DESC 'MemoryCapacity describes the type of Memory that can be installed on a PhysicalElement and its minimum/maximum configurations. Information on what memory is currently "installed", versus an Element's min/max requirements, is located in instances of the PhysicalMemory class.' SUP cim22PhysicalCapacity MUST (orderedCimModelPath $ cimMemoryType) MAY (cimMinimumMemoryCapacity $ cimMaximumMemoryCapacity) ) ( <oid-nf13> NAME 'cim22MemoryCapacityNameForm' OC cim22MemoryCapacity MUST (orderedCimModelPath) Expires 6/30/00 [Page 9]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ) ( <sr13> NAME 'cim22MemoryCapacityStructureRule' FORM cim22MemoryCapacityNameForm ) 3.6 cim22ConfigurationCapacity Capacity includes the number of power supplies, fans, disk drives, etc. that can be connected to or placed on/into a physical element (and the number that must be connected/added/removed at a time). cim22ElementCapacityAuxClass identifies the physical element whose configuration is described. This class does NOT represent the tradeoffs required of one resource for another. It simply represents capacities. For a StorageLibrary, there are only 2 valid configurations - 9 TapeDrives with 88 Slots, or 3 TapeDrives with 264 Slots. it only conveys that 'up to' 9 Drives and 'up to' 264 slots are available and supported. ( <oid-at83> NAME 'cimObjectType' DESC 'The type of object (power supply, fan, disk drive, ...) whose capacities are indicated. This information is part of the class' key.' SYNTAX integer SINGLE-VALUE ) ( <oid-at84> NAME 'cimOtherTypeDescription' DESC 'A string describing the object type - used when the ObjectType property is set to 0 ("Other"). OtherTypeDescription should be set to NULL when ObjectType is any value other than 0.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at85> NAME 'cimMinimumCapacity' DESC 'Minimum number of Elements of type, ObjectType, that must be installed.' SYNTAX integer SINGLE-VALUE ) ( <oid-at86> NAME 'cimMaximumCapacity' DESC 'Maximum number of Elements of type, ObjectType, that may be installed.' SYNTAX integer SINGLE-VALUE ) ( <oid-at87> NAME 'cimIncrement' Expires 6/30/00 [Page 10]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 DESC 'Increment in which Elements must be added or removed.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc51> NAME 'cim22ConfigurationCapacity' DESC 'ConfigurationCapacity provides information on the minimum and maximum numbers of power supplies, fans, disk drives, etc. that can be connected to or placed on/into a PhysicalElement (and the number that must be connected/added/removed at a time). The PhysicalElement whose configuration is described is identified using the ElementCapacity association, inherited from PhysicalCapacity. The object whose capacities are indicated (ie, the power supply or fan) is identified in the ObjectType property of this class. Since the same min/max configurations can apply to multiple instances, this class is not defined as "weak". Examples of the use of the ConfigurationCapacity class are to describe that a "control unit" Chassis may be connected to (at most) 4 other I/O chassis, or to describe what a StorageLibrary's cabinet may contain. Continuing the latter example, a particular StorageLibrary's cabinet might hold a minimum of 3 and a maximum of 9 TapeDrives, and a minimum of 88 and a maximum of 264 StorageMediaLocations ("Slots"). This information would be described in two instances of ConfigurationCapacity, both associated to the StorageLibrary's PhysicalPackage. This class does NOT represent the tradeoffs that are likely to be required of one resource for another. It simply represents capacities. In the case of the StorageLibrary, there may be only 2 valid configurations - 9 TapeDrives with 88 Slots, or 3 TapeDrives with 264 Slots. This class only conveys that "up to" 9 Drives and "up to" 264 slots may be available and are supported.' SUP cim22PhysicalCapacity MUST (orderedCimModelPath $ cimObjectType) MAY (cimOtherTypeDescription $ cimMinimumCapacity $ cimMaximumCapacity $ cimIncrement) ) ( <oid-nf14> NAME 'cim22ConfigurationCapacityNameForm' OC cim22ConfigurationCapacity MUST (orderedCimModelPath) ) ( <sr14> NAME 'cim22ConfigurationCapacityStructureRule' FORM cim22ConfigurationCapacityNameForm ) Expires 6/30/00 [Page 11]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 3.7 cim22ReplacementSet A replacement set is a group of physical elements that must be replaced or FRUed together. For example, when replacing a memory card, the component memory chips could be removed and replaced as well. ( <oid-oc52> NAME 'cim22ReplacementSet' DESC 'The ReplacementSet class aggregates PhysicalElements that must be "replaced" or "FRUed" together. For example, when replacing a memory card, the component memory chips could be removed and replaced as well. Or, a set of memory chips may be specified to be replaced or upgraded together using this association.' SUP top MUST (cimName $ orderedCimModelPath) MAY (cimDescription) ) ( <oid-nf15> NAME 'cim22ReplacementSetNameForm' OC cim22ReplacementSet MUST (orderedCimModelPath) ) ( <sr15> NAME 'cim22ReplacementSetStructureRule' FORM cim22ReplacementSetNameForm ) The following content rule specifies the auxiliary classes that may be attached to cim22ReplacementSet. ( <oid-oc52> NAME 'cim22ReplacementSetContentRule' DESC 'The auxiliary classes that may be attached to cim22ReplacementSet' AUX (cim22ParticipatesInSetAuxClass) ) 3.8 cim22ParticipatesInSetAuxClass This class shows which physical elements should be replaced together. ( <oid-oc53> NAME 'cim22ParticipatesInSetAuxClass' DESC 'ParticipatesInSet indicates which PhysicalElements should be replaced together. Attribute cimSetRef points to cim22ReplacementSet and attribute cimElementRef points to cim22PhysicalElement.' SUP top AUXILIARY MAY (cimSetRef $ cimElementRef) Expires 6/30/00 [Page 12]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ) 3.9 cim22PhysicalPackage A physical package contains or hosts components. Examples are a rack enclosure or an adapter Card. ( <oid-at89> NAME 'cimRemovable' DESC 'A PhysicalPackage is Removable if it is designed to be taken in and out of the physical container in which it is normally found, without impairing the function of the overall packaging. A Package can still be Removable if power must be "off" in order to perform the removal. If power can be "on" and the Package removed, then the Element is both Removable and HotSwappable. For example, an extra battery in a laptop is Removable, as is a disk drive Package inserted using SCA connectors. However, the latter is also HotSwappable. A laptop's display is not Removable, nor is a non-redundant power supply. Removing these components would impact the function of the overall packaging or is impossible due to the tight integration of the Package.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at90> NAME 'cimReplaceable' DESC 'A PhysicalPackage is Replaceable if it is possible to replace (FRU or upgrade) the Element with a physically different one. For example, some ComputerSystems allow the main Processor chip to be upgraded to one of a higher clock rating. In this case, the Processor is said to be Replaceable. Another example is a power supply Package mounted on sliding rails. All Removable packages are inherently Replaceable.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at91> NAME 'cimHotSwappable' DESC 'A PhysicalPackage is HotSwappable if it is possible to replace the Element with a physically different but equivalent one while the containing Package has power applied to it (ie, is "on"). For example, a disk drive Package inserted using SCA connectors is both Removable and HotSwappable. All HotSwappable packages are inherently Removable and Replaceable.' SYNTAX boolean SINGLE-VALUE ) Expires 6/30/00 [Page 13]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-at92> NAME 'cimHeight' DESC 'The height of the PhysicalPackage in inches.' SUP CimFloat32 SINGLE-VALUE ) ( <oid-at93> NAME 'cimDepth' DESC 'The depth of the PhysicalPackage in inches.' SUP CimFloat32 SINGLE-VALUE ) ( <oid-at94> NAME 'cimWidth' DESC 'The width of the PhysicalPackage in inches.' SUp CimFloat32 SINGLE-VALUE ) ( <oid-at95> NAME 'cimWeight' DESC 'The weight of the PhysicalPackage in pounds.' SUP CimFloat32 SINGLE-VALUE ) ( <oid-oc54> NAME 'cim22PhysicalPackage' DESC 'The PhysicalPackage class represents PhysicalElements that contain or host other components. Examples are a Rack enclosure or an adapter Card.' SUP cim22PhysicalElement MAY (cimRemovable $ cimReplaceable $ cimHotSwappable $ cimHeight $ cimDepth $ cimWidth $ cimWeight) ) ( <oid-nf16> NAME 'cim22PhysicalPackageNameForm' OC cim22PhysicalPackage MUST (orderedCimModelPath) ) ( <sr16> NAME 'cim22PhysicalPackageStructureRule' FORM cim22PhysicalPackageNameForm ) The following content rule specifies the auxiliary classes that may be attached to cim22PhysicalPackage. ( <oid-oc54> NAME 'cim22PhysicalPackageContentRule' DESC 'The auxiliary classes that may be attached to cim22PhysicalPackage' AUX (cim22ContainerAuxClass $ cim22PackageInChassisAuxClass $ cim22PackagedComponentAuxClass $ cim22PackageInConnectorAuxClass $ cim22PackageInSlotAuxClass $ cim22ConnectorOnPackageAuxClass $ Expires 6/30/00 [Page 14]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 cim22ComputerSystemPackageAuxClass $ cim22LibraryPackageAuxClass $ cim22PackageCoolingAuxClass $ cim22PackageTempSensorAuxClass $ cim22PackageAlarmAuxClass $ cim22ProductPhysicalElementsAuxClass $ cim22FRUPhysicalElementsAuxClass $ cim22PhysicalElementLocationAuxClass $ cim22ElementCapacityAuxClass $ cim22ParticipatesInSetAuxClass $ cim22ElementsLinkedAuxClass $ cim22CollectedMSEsAuxClass $ cim22ElementConfigurationAuxClass $ cim22ElementSettingAuxClass $ cim22DependencyAuxClass $ cim22ProvidesServiceToElementAuxClass $ cim22ComponentAuxClass $ cim22SystemComponentAuxClass) ) 3.10 cim22ContainerAuxClass This class represents the relationship between a contained and a containing PhysicalElement. ( <oid-at96> NAME 'cimLocationWithinContainer' DESC 'A free-form string representing the positioning of the PhysicalElement within the PhysicalPackage. This string could supplement or be used in place of instantiating the cimLocation object.' SYNTAX string SINGLE-VALUE ) ( <oid-oc55> NAME 'cim22ContainerAuxClass' DESC 'The Container association represents the relationship between a contained and a containing PhysicalElement. A containing object must be a PhysicalPackage. Attribute cimGroupComponentRef points to cim22PhysicalPackage and attribute cimPartComponentRef points to cim22PhysicalElement.' SUP cim22ComponentAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef $ cimLocationWithinContainer) ) 3.11 cim22PhysicalFrame A physical frame is a generic frame enclosure. ( <oid-at97> NAME 'cimCableManagementStrategy' DESC 'CableManagementStrategy is a free-form string that contains information on how the various cables are connected and bundled for the Frame. With many networking, Expires 6/30/00 [Page 15]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 storage-related and power cables, cable management can be a complex and challenging endeavor. This string property contains information to aid in assembly and service of the Frame.' SYNTAX string SINGLE-VALUE ) ( <oid-at100> NAME 'cimLockPresent' DESC 'Boolean indicating whether the Frame is protected with a lock.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at101> NAME 'cimAudibleAlarm' DESC 'Boolean indicating whether the Frame is equipped with an audible alarm.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at102> NAME 'cimVisibleAlarm' DESC 'Boolean indicating that the equipment includes a visible alarm.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at103> NAME 'cimSecurityBreach' DESC 'SecurityBreach is an enumerated, integer-valued property indicating whether a physical breach of the Frame was attempted but unsuccessful (value=4) or attempted and successful (5). Also, the values, "Unknown", "Other" or "No Breach", can be specified.' SYNTAX integer SINGLE-VALUE ) ( <oid-at104> NAME 'cimBreachDescription' DESC 'BreachDescription is a free-form string providing more information if the SecurityBreach property indicates that a breach or some other security-related event occurred.' SYNTAX string SINGLE-VALUE ) ( <oid-at105> NAME 'cimIsLocked' DESC 'Boolean indicating that the Frame is currently locked.' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc56> NAME 'cim22PhysicalFrame' SUP cim22PhysicalPackage Expires 6/30/00 [Page 16]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 MAY (cimCableManagementStrategy $ cimLockPresent $ cimAudibleAlarm $ cimVisibleAlarm $ cimSecurityBreach $ cimBreachDescription $ cimIsLocked) ) ( <oid-nf17> NAME 'cim22PhysicalFrameNameForm' OC cim22PhysicalFrame MUST (orderedCimModelPath) ) ( <sr17> NAME 'cim22PhysicalFrameStructureRule' FORM cim22PhysicalFrameNameForm ) 3.12 cim22Rack Racks are enclosures in which chassis are placed. Typically they are nothing more than the enclosure, and the chassis packages all functioning componentry. ( <oid-at106> NAME 'cimTypeOfRack' DESC 'Enumeration indicating the type of Rack. Information such as "Telco" rack (value=2) or standard 19 inch rack (1) can be specified. The country for which the Rack is manufactured is defined in the the CountryDesignation property.' SYNTAX integer SINGLE-VALUE ) ( <oid-at107> NAME 'cimCountryDesignation' DESC 'Designation of the country for which the Rack is designed. Country code strings are as defined by ISO/IEC 3166. The rack type is specified in the TypeOfRack property.' SYNTAX string SINGLE-VALUE ) ( <oid-oc57> NAME 'cim22Rack' DESC 'A Rack is a PhysicalFrame that represents an enclosure in which Chassis are placed. Typically a Rack is nothing more than the enclosure, and all the functioning componentry is packaged in the Chassis, loaded in the Rack.' SUP cim22PhysicalFrame MAY (cimTypeOfRack $ cimCountryDesignation) ) The following content rule specifies the auxiliary classes that may be attached to cim22Rack. Expires 6/30/00 [Page 17]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-oc57> NAME 'cim22RackContentRule' DESC 'The auxiliary classes that may be attached to cim22Rack' AUX (cim22ChassisInRackAuxClass) ) 3.13 cim22Chassis Chassis enclose other elements and provide definable functionality. ( <oid-at108> NAME 'cimNumberOfPowerCords' DESC 'Integer indicating the number of power cords which must be connected to the Chassis, for all the componentry to operate.' SYNTAX integer SINGLE-VALUE ) ( <oid-at109> NAME 'cimCurrentRequiredOrProduced' DESC 'Current required by the Chassis at 120V. If power is provided by the Chassis (as in the case of a UPS), this property may indicate the amperage produced, as a negative number.' SYNTAX integer SINGLE-VALUE ) ( <oid-at110> NAME 'cimHeatGeneration' DESC 'Amount of heat generated by the Chassis in BTU/hour.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc58> NAME 'cim22Chassis' DESC 'The Chassis class represents the PhysicalElements that enclose other Elements and provide definable functionality, such as a desktop, processing node, UPS, disk or tape storage, or a combination of these.' SUP cim22PhysicalFrame MAY (cimNumberOfPowerCords $ cimCurrentRequiredOrProduced $ cimHeatGeneration) ) ( <oid-nf18> NAME 'cim22ChassisNameForm' OC cim22Chassis MUST (orderedCimModelPath) ) ( <sr18> NAME 'cim22ChassisStructureRule' FORM cim22ChassisNameForm ) Expires 6/30/00 [Page 18]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 The following content rule specifies the auxiliary classes that may be attached to cim22Chassis. ( <oid-oc58> NAME 'cim22ChassisContentRule' DESC 'The auxiliary classes that may be attached to cim22Chassis' AUX (cim22ChassisInRackAuxClass $ cim22PackageInChassisAuxClass $ cim22DockedAuxClass) ) 3.14 cim22ChassisInRackAuxClass This class makes explicit the 'containing' relationship between the Rack and the Chassis. ( <oid-at113> NAME 'cimBottomU' DESC 'An integer indicating the lowest or "bottom" U in which the Chassis is mounted. A "U" is a standard unit of measure for the height of a Rack or rack-mountable component. It is equal to 1.75 inches or 4.445 cm.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc59> NAME 'cim22ChassisInRackAuxClass' DESC 'Racks, as simple enclosures, contain Chassis that provide the physical componentry realizing processing nodes, storage devices, UPSs, etc. The ChassisInRack association makes explicit the "containing" relationship between the Rack and the Chassis.Attribute cimGroupComponentRef points to cim22Rack and attribute cimPartComponentRef points to cim22Chassis.' SUP cim22ContainerAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef $ cimLocationWithinContainer $ cimBottomU) ) 3.15 cim22PackageInChassisAuxClass This class makes the containment relationship between a chassis and other packages explicit. ( <oid-oc60> NAME 'cim22PackageInChassisAuxClass' DESC 'A Chassis can contain other Packages, such as other Chassis and Cards. The PackageInChassis association makes explicit this relationship. Attribute cimGroupComponentRef points to cim22Chassis and attribute cimPartComponentRef points to cim22PhysicalPackage.' SUP cim22ContainerAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef $ Expires 6/30/00 [Page 19]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 cimLocationWithinContainer) ) 3.16 cim22DockedAuxClass This class makes explicit the relationship between a laptop, a type of chassis, which docks in another type of chassis, a docking station. ( <oid-oc61> NAME 'cim22DockedAuxClass' DESC 'A laptop, a type of Chassis, may be docked in another type of Chassis, a Docking Station. This is the relationship represented by the Docked association. Because this is such a typical relationship, it is explicitly described. Both attributes point to cim22Chassis objects.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.17 cim22Card This class represents a type of physical container that can be plugged into another Card or HostingBoard, or is itself a HostingBoard/Motherboard in a Chassis. It includes any package capable of carrying signals and providing a mounting point for PhysicalComponents, such as Chips, or other PhysicalPackages, such as other Cards. ( <oid-at114> NAME 'cimHostingBoard' DESC 'Boolean indicating that this Card is a Motherboard or, more generically, a baseboard in a Chassis.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at115> NAME 'cimSlotLayout' DESC 'SlotLayout is a free-form string that describes the slot positioning, typical usage, restrictions, individual slot spacings or any other pertinent information for the slots on a Card.' SYNTAX string SINGLE-VALUE ) ( <oid-at116> NAME 'cimRequiresDaughterBoard' DESC 'Boolean indicating that at least one daughterboard or auxiliary Card is required in order to function properly.' SYNTAX boolean SINGLE-VALUE ) Expires 6/30/00 [Page 20]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-at117> NAME 'cimSpecialRequirements' DESC 'Boolean indicating that this Card is physically unique from other Cards of the same type and therefore requires a special Slot. For example, a double-wide Card requires two Slots. Another example is where a certain Card may be used for the same general function as other Cards but requires a special Slot (e.g., extra long), whereas the other Cards can be placed in any available Slot. If set to TRUE, then the corresponding property, RequirementsDescription, should specify the nature of the uniqueness or purpose of the Card.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at118> NAME 'cimRequirementsDescription' DESC 'A free-form string describing the way(s) in which this Card is physically unique from other Cards. This property only has meaning when the corresponding boolean property, SpecialRequirements, is set to TRUE.' SYNTAX string SINGLE-VALUE ) ( <oid-at119> NAME 'cimOperatingVoltages' DESC 'Operating voltages required by the Card.' SYNTAX ) ( <oid-oc62> NAME 'cim22Card' DESC 'The Card class represents a type of physical container that can be plugged into another Card or HostingBoard, or is itself a HostingBoard/Motherboard in a Chassis. The cim22Card class includes any package capable of carrying signals and providing a mounting point for PhysicalComponents, such as Chips, or other PhysicalPackages, such as other Cards.' SUP cim22PhysicalPackage MAY (cimHostingBoard $ cimSlotLayout $ cimRequiresDaughterBoard $ cimSpecialRequirements $ cimRequirementsDescription $ cimOperatingVoltages) ) The following content rule specifies the auxiliary classes that may be attached to cim22Card. ( <oid-oc62> NAME 'cim22CardContentRule' DESC 'The auxiliary classes that may be attached to cim22Card' AUX (cim22CardOnCardAuxClass $ cim22MemoryOnCardAuxClass $ cim22CardInSlotAuxClass) Expires 6/30/00 [Page 21]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ) 3.18 cim22SystemBusCard System bus cards require additional attributes, detailing the card's bus type and data width, which dictate the type of slot into which the card can be inserted. For example, attributes can define that a card is a PCI, 64 bit adapter. ( <oid-at120> NAME 'cimBusType' DESC 'An enumerated integer describing the System bus type for this Card. It indicates the type of Slot into which the Card can plug.' SYNTAX integer SINGLE-VALUE ) ( <oid-at121> NAME 'cimBusWidth' DESC 'System bus width (in bits) required by this Card. If "unknown", enter 0. If "other" than the values, 8, 16, 32, 64 or 128, enter 1.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc63> NAME 'cim22SystemBusCard' DESC 'The SystemBusCard class represents additional information for a cimCard, detailing the Card's bus type and data width. These properties dictate the type of Slot into which the Card can be inserted. For example, using the properties of this class, one can define that a Card is a PCI, 64 bit adapter.' SUP cim22Card MAY (cimBusType $ cimBusWidth) ) 3.19 cim22CardOnCardAuxClass Cards may be plugged into Motherboards/baseboards, are daughtercards of an adapter, or support special Card-like modules. This auxiliary class describes these relationships. ( <oid-at122> NAME 'cimMountOrSlotDescription' DESC 'A string describing and identifying how the Card is mounted on or plugged into the "other" Card. Slot information could be included in this field and may be sufficient for certain management purposes. If so, this avoids creating instantiations of Connector/Slot objects just to model the relationship of Cards to HostingBoards or other adapters. On the other hand, if Slot and Connector Expires 6/30/00 [Page 22]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 information is available, this field could be used to provide more detailed mounting or slot insertion data.' SYNTAX string SINGLE-VALUE ) ( <oid-oc64> NAME 'cim22CardOnCardAuxClass' DESC 'Cards may be plugged into Motherboards/baseboards, are daughtercards of an adapter, or support special Card-like modules. These relationships are described by the CardOnCard association. Both reference attributes point to cim22Card objects.' SUP cim22ContainerAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef $ cimLocationWithinContainer $ cimMountOrSlotDescription) ) 3.20 cim22StorageMediaLocation A storage media location holds media and goes beyond being just a location used by a storage library. ( <oid-at123> NAME 'cimLocationType' DESC 'The type of Location. For example, whether this is an individual Media "Slot" (value=2), a MediaAccessDevice (value=4) or a "Magazine" (value=3) is indicated in this property.' SYNTAX integer SINGLE-VALUE ) ( <oid-at124> NAME 'cimLocationCoordinates' DESC 'LocationCoordinates represent the physical location of the the StorageMediaLocation instance. The property is defined as a free-form string to allow the location information to be described in vendor-unique terminology.' SYNTAX string SINGLE-VALUE ) ( <oid-at127> NAME 'cimMediaCapacity' DESC 'A StorageMediaLocation may hold more than one PhysicalMedia - for example, a Magazine. This property indicates the PhysicalMedia capacity of the Location.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc65> NAME 'cim22StorageMediaLocation' DESC 'StorageMediaLocation is a PhysicalElement where PhysicalMedia may be placed. This class describes an entity that holds Media and is not just a "place" (as is conveyed Expires 6/30/00 [Page 23]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 by the cim22Location object). This class is typically used in the context of a StorageLibrary. Examples of StorageMediaLocations are MediaAccessDevices, InterLibraryPorts or "slots" in a Library panel.' SUP cim22PhysicalPackage MAY (cimLocationType $ cimLocationCoordinates $ cimMediaCapacity) ) ( <oid-nf19> NAME 'cim22StorageMediaLocationNameForm' OC cim22StorageMediaLocation MUST (orderedCimModelPath) ) ( <sr19> NAME 'cim22StorageMediaLocationStructureRule' FORM cim22StorageMediaLocationNameForm ) The following content rule specifies the auxiliary classes that may be attached to cim22StorageMediaLocation. ( <oid-oc65> NAME 'cim22StorageMediaLocationContentRule' DESC 'The auxiliary classes that may be attached to cim22StorageMediaLocation' AUX (cim22DeviceServicesLocationAuxClass $ cim22PhysicalMediaInLocationAuxClass) ) 3.21 cim22PhysicalComponent A physical component either can not or does not need to be decomposed into its constituent parts. For example, an ASIC can not be further decomposed and a tape for data storage does not need to be decomposed. Any element that is not a link, connector, or package is subclassed from this class. ( <oid-oc66> NAME 'cim22PhysicalComponent' DESC 'The PhysicalComponent class represents any low-level or basic Component within a Package. A Component object either can not or does not need to be decomposed into its constituent parts. For example, an ASIC (or Chip) can not be further decomposed. A tape for data storage (PhysicalMedia) does not need to be decomposed. Any PhysicalElement that is not a Link, Connector, or Package is a descendent (or member) of this class. For example, the UART chipset on an internal modem Card would be a subclass (if additional properties or associations are defined) or an instance of PhysicalComponent.' SUP cim22PhysicalElement Expires 6/30/00 [Page 24]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 MAY (cimRemovable $ cimReplaceable $ cimHotSwappable) ) The following content rule specifies the auxiliary classes that may be attached to cim22PhysicalComponent. ( <oid-oc66> NAME 'cim22PhysicalComponentContentRule' DESC 'The auxiliary classes that may be attached to cim22PhysicalComponent' AUX (cim22PackagedComponentAuxClass $ cim22RealizesAuxClass $ cim22ProductPhysicalElementsAuxClass $ cim22FRUPhysicalElementsAuxClass $ cim22PhysicalElementLocationAuxClass $ cim22ElementCapacityAuxClass $ cim22ParticipatesInSetAuxClass $ cim22ContainerAuxClass $ cim22ElementsLinkedAuxClass $ cim22CollectedMSEsAuxClass $ cim22ElementConfigurationAuxClass $ cim22ElementSettingAuxClass $ cim22DependencyAuxClass $ cim22ProvidesServiceToElementAuxClass $ cim22ComponentAuxClass $ cim22SystemComponentAuxClass) ) 3.22 cim22PackagedComponentAuxClass As a physical package typically contains a component, this class makes this relationship explicit. The word, 'typically', is used because a Component may be removed from, or not yet inserted into, its containing Package (ie, the Removable boolean is TRUE). Therefore, a Component may not always be associated with a container. ( <oid-oc67> NAME 'cim22PackagedComponentAuxClass' DESC 'A Component is typically contained by a PhysicalPackage, such as a Chassis or Card. The PackagedComponent association makes this relationship explicit. In the first sentence, the word, "typically", is used. This is because a Component may be removed from, or not yet inserted into, its containing Package (ie, the Removable boolean is TRUE). Therefore, a Component may not always be associated with a container. Attribute cimGroupComponentRef points to cim22PhysicalPackage and attribute cimPartComponentRef points to cim22PhysicalComponent.' SUP cim22ContainerAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef $ cimLocationWithinContainer) ) Expires 6/30/00 [Page 25]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 3.23 cim22Chip A chip is of IC hardware, including ASICs, processors, and memory chips. ( <oid-at128> NAME 'cimFormFactor' DESC 'The implementation form factor for the Chip. For example, values such as SIMM (7), TSOP (9) or PGA (10) can be specified.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc68> NAME 'cim22Chip' DESC 'The Chip class represents any type of integrated circuit hardware, including ASICs, processors, memory chips, etc.' SUP cim22PhysicalComponent MAY (cimFormFactor) ) 3.24 cim22PhysicalMemory Physical memory are low level memory devices. ( <oid-at129> NAME 'cimTotalWidth' DESC 'Total width, in bits, of the PhysicalMemory, including check or error correction bits. If there are no error correction bits, the value in this property should match that specified for DataWidth.' SYNTAX integer SINGLE-VALUE ) ( <oid-at130> NAME 'cimDataWidth' DESC 'Data width of the PhysicalMemory, in bits. A data width of 0 and a TotalWidth of 8 would indicate that the Memory is solely used to provide error correction bits.' SYNTAX integer SINGLE-VALUE ) ( <oid-at131> NAME 'cimSpeed' DESC 'The speed of the PhysicalMemory, in nanoseconds.' SYNTAX integer SINGLE-VALUE ) ( <oid-at132> NAME 'cimCapacity' DESC 'The total capacity of this PhysicalMemory, in bytes.' SYNTAX integer SINGLE-VALUE ) Expires 6/30/00 [Page 26]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-at133> NAME 'cimBankLabel' DESC 'A string identifying the physically labeled bank where the Memory is located - for example, "Bank 0" or "Bank A".' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at134> NAME 'cimPositionInRow' DESC 'Specifies the position of the PhysicalMemory in a "row". For example, if it takes two 8-bit memory devices to form a 16-bit row, then a value of "2"means that this Memory is the second device. 0 is an invalid value for this property.' SYNTAX integer SINGLE-VALUE ) ( <oid-at135> NAME 'cimInterleavePosition' DESC 'The position of this PhysicalMemory in an interleave. 0 indicates non-interleaved. 1 indicates the first position, 2 the second position and so on. For example, in a 2:1 interleave, a value of "1" would indicate that the Memory is in the "even" position.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc69> NAME 'cim22PhysicalMemory' DESC 'PhysicalMemory is a subclass of cim22Chip, representing low level memory devices - SIMMS, DIMMs, raw memory chips, etc.' SUP cim22Chip MAY (cimFormFactor $ cimMemoryType $ cimTotalWidth $ cimDataWidth $ cimSpeed $ cimCapacity $ cimBankLabel $ cimPositionInRow $ cimInterleavePosition) ) The following content rule specifies the auxiliary classes that may be attached to cim22PhysicalMemory. ( <oid-oc69> NAME 'cim22PhysicalMemoryContentRule' DESC 'The auxiliary classes that may be attached to cim22PhysicalMemory' AUX (cim22MemoryOnCardAuxClass $ cim22MemoryWithMediaAuxClass) ) 3.25 cim22MemoryOnCardAuxClass Hosting boards, adapter Cards, etc., can hold physical memory. Therefore, this class represents that relationship. Expires 6/30/00 [Page 27]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-oc70> NAME 'cim22MemoryOnCardAuxClass' DESC 'PhysicalMemory can be located on HostingBoards, adapter Cards, etc. This association explicitly defines this relationship of Memory to Cards. Attribute cimGroupComponentRef points to cim22Card. Attribute cimPartComponentRef points to cim22PhysicalMemory.' SUP cim22PackagedComponentAuxClass MAY (cimGroupComponentRef $ cimPartComponentRef $ cimLocationWithinContainer) ) 3.26 cim22PhysicalMedia Physical media are any type of documentation or storage medium, typically removable media. However, this class can also model 'sealed' media where dmtfPackagedComponentAuxClass associates the media with the physical package. ( <oid-at136> NAME 'cimMediaType' DESC 'Specifies the type of the PhysicalMedia, as an enumerated integer. The MediaDescription property is used to provide more explicit definition of the Media type, whether it is pre-formatted, compatability features, etc.' SYNTAX integer SINGLE-VALUE ) ( <oid-at137> NAME 'cimMediaDescription' DESC 'Additional detail related to the MediaType enumeration. For example, if value 3 ("QIC Cartridge") is specified, this property could indicate whether the tape is wide or 1/4 inch, whether it is pre-formatted, whether it is Travan compatible, etc.' SYNTAX string SINGLE-VALUE ) ( <oid-at138> NAME 'cimWriteProtectOn' DESC 'Boolean specifying whether the Media is currently write protected by some kind of physical mechanism, such as a protect tab on a floppy diskette.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at139> NAME 'cimCleanerMedia' DESC 'Boolean indicating that the PhysicalMedia is used for cleaning purposes and not data storage.' SYNTAX boolean SINGLE-VALUE ) Expires 6/30/00 [Page 28]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-at140> NAME 'cimMediaSize' DESC 'Size of the Media in inches. For example, "3.5" would be entered for a 3.5 inch disk, or "12" would be entered for a 12 inch optical disk. On the other hand, "0.5" would be defined for a 1/2 inch tape.' SUP cim22Float32 SINGLE-VALUE ) ( <oid-at141> NAME 'cimMaxMounts' DESC 'For removable Media, the maximum number of times that the Media can be mounted before it should be retired. For cleaner Media, this is the maximum number of Drive cleans that can be performed. For nonremovable Media, such as hard disks, this property is not applicable and should be set to 0.' SYNTAX integer SINGLE-VALUE ) ( <oid-at142> NAME 'cimDualSided' DESC 'Boolean indicating that the Media has two recording sides (TRUE) or only a single side (FALSE). Examples of dual sided Media include DVD-ROM and some optical disks. Examples of single sided Media are tapes and CD-ROM.' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc71> NAME 'cim22PhysicalMedia' DESC 'The PhysicalMedia class represents any type of documentation or storage medium, such as tapes, CDROMs, etc. This class is typically used to locate and manage Removable Media (versus Media sealed with the MediaAccessDevice, as a single Package, as is the case with hard disks). However, "sealed" Media can also be modeled using this class, where the Media would then be associated with the PhysicalPackage using the PackagedComponent relationship.' SUP cim22PhysicalComponent MAY (cimCapacity $ cimMediaType $ cimMediaDescription $ cimWriteProtectOn $ cimCleanerMedia $ cimMediaSize $ cimMaxMounts $ cimDualSided $ cimPhysicalLabels $ cimLabelStates $ cimLabelFormats) ) ( <oid-nf20> NAME 'cim22PhysicalMemoryNameForm' OC cim22PhysicalMemory MUST (orderedCimModelPath) ) Expires 6/30/00 [Page 29]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <sr20> NAME 'cim22PhysicalMemoryStructureRule' FORM cim22PhysicalMemoryNameForm ) The following content rule specifies the auxiliary classes that may be attached to cim22PhysicalMedia. ( <oid-oc71> NAME 'cim22PhysicalMediaContentRule' DESC 'The auxiliary classes that may be attached to cim22PhysicalMedia' AUX (cim22MemoryWithMediaAuxClass $ cim22PhysicalMediaInLocationAuxClass) ) 3.27 cim22MemoryWithMediaAuxClass This class shows that memory is associated with a physical media and its cartridge and provides identification and also stores user- specific data. ( <oid-oc72> NAME 'cim22MemoryWithMediaAuxClass' DESC 'MemoryWithMedia indicates that Memory is associated with a PhysicalMedia and its cartridge. The Memory provides media identification and also stores user-specific data. Attribute cimAntecedentRef points to cim22PhysicalMemory and attribute cimDependentRef points to cim22PhysicalMedia.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.28 cim22PhysicalMediaInLocationAuxClass Within a storage library, all media should be accounted for, and be present in some storage location. In addition, one can determine if a location is empty or full based on whether this auxiliary class is attached to a cim22StorageMediaLocation object. ( <oid-oc73> NAME 'cim22PhysicalMediaInLocationAuxClass' DESC 'Within a StorageLibrary, all Media should be accounted for, and be present in some Storage Location. This relationship is made explicit by the PhysicalMediaInLocation association. In addition, one can determine if a Location is empty or full based on whether this association exists for the StorageMediaLocation. Attribute cimAntecedentRef points to cim22StorageMediaLocation and attribute cimDependentRef points to cim22PhysicalMedia.' SUP cim22DependencyAuxClass AUXILIARY Expires 6/30/00 [Page 30]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 MAY (cimAntecedentRef $ cimDependentRef) ) 3.29 cim22PhysicalTape This class represents data for a tape Media, including information on the length and whether it must be unloaded from BOT. ( <oid-at146> NAME 'cimTapeLength' DESC 'The physical length of the Tape in feet.' SUP cim22Float32 SINGLE-VALUE ) ( <oid-at147> NAME 'cimUnloadAnywhere' DESC 'Boolean set to TRUE if the Tape can be unloaded at any position on the Media. It is set to FALSE if the tape must be at a certain position for unload - such as at the beginning of tape (BOT) area, or at mid-tape point for TapeDrives with mid-tape load.' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc74> NAME 'cim22PhysicalTape' DESC 'The PhysicalTape class represents additional data for a Tape Media. Information on the tape length and whether it must be unloaded from BOT are properties of this class.' SUP cim22PhysicalMedia MAY (cimTapeLength $ cimUnloadAnywhere) ) 3.30 cim22PhysicalLink Physical links are the cabling together of physical elements, including cables and links. Rather than model the numerous physical cables within a physical package or network, this class is intended for those cases where the cables or links are either critical components or important assets. ( <oid-at149> NAME 'cimMaxLength' DESC 'The maximum length of the PhysicalLink in feet.' SUP cim22Float64 SINGLE-VALUE ) ( <oid-at150> NAME 'cimLength' DESC 'The current length of the PhysicalLink in feet. For some connections, especially wireless technologies, this property may not be applicable and should be left uninitialized.' Expires 6/30/00 [Page 31]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 SUP cim22Float64 SINGLE-VALUE ) ( <oid-at151> NAME 'cimWired' DESC 'Boolean indicating whether the PhysicalLink is an actual cable (TRUE) or a wireless connection (FALSE).' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc75> NAME 'cim22PhysicalLink' DESC 'The PhysicalLink class represents the cabling of PhysicalElements together. For example, serial or Ethernet cables, and infrared Links would be subclasses (if additional properties or associations are defined) or instances of PhysicalLink. In many cases, the numerous physical cables within a PhysicalPackage or Network will not be modeled. However, where these cables or Links are critical components, or are tagged assets of the company, these objects can be instantiated using this class or one of its descendent classes.' SUP cim22PhysicalElement MAY (cimMaxLength $ cimLength $ cimWired $ cimMediaType) ) The following content rule specifies the auxiliary classes that may be attached to cim22PhysicalLink. ( <oid-oc75> NAME 'cim22PhysicalLinkContentRule' DESC 'The auxiliary classes that may be attached to cim22PhysicalLink' AUX (cim22ElementsLinkedAuxClass $ cim22LinkHasConnectorAuxClass $ cim22RealizesAuxClass $ cim22ProductPhysicalElementsAuxClass $ cim22FRUPhysicalElementsAuxClass $ cim22PhysicalElementLocationAuxClass $ cim22ElementCapacityAuxClass $ cim22ParticipatesInSetAuxClass $ cim22ContainerAuxClass $ cim22CollectedMSEsAuxClass $ cim22ElementConfigurationAuxClass $ cim22ElementSettingAuxClass $ cim22DependencyAuxClass $ cim22ProvidesServiceToElementAuxClass $ cim22ComponentAuxClass $ cim22SystemComponentAuxClass) ) Expires 6/30/00 [Page 32]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 3.31 cim22ElementsLinkedAuxClass This class shows which physical elements are cabled together by a physical link. ( <oid-oc76> NAME 'cim22ElementsLinkedAuxClass' DESC 'The ElementsLinked association indicates which PhysicalElements are cabled together by a PhysicalLink. Attribute cimAntecedentRef points to cim22PhysicalLink and attribute cimDependentRef points to cim22PhysicalElement.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.32 cim22PhysicalConnector This class represents any physical element that is used to connect to other elements. Any object that can be used to connect and transmit signals or power between two or more physical elements is a descendant of this class. For example, slots and D-shell connectors are types of physical connectors. ( <oid-at152> NAME 'cimConnectorPinout' DESC 'A free-form string describing the pin configuration and signal usage of a PhysicalConnector.' SYNTAX string SINGLE-VALUE ) ( <oid-at153> NAME 'cimConnectorType' DESC 'An array of integers defining the type of PhysicalConnector. An array is specified to allow the description of "combinations" of Connector information. For example, one array entry could specify RS-232 (value=25), another DB-25 (value=23) and a third entry define the Connector as "Male" (value=2).' SYNTAX integer ) ( <oid-oc77> NAME 'cim22PhysicalConnector' DESC 'The PhysicalConnector class represents any PhysicalElement that is used to connect to other Elements. Any object that can be used to connect and transmit signals or power between two or more PhysicalElements is a descendant (or member) of this class. For example, Slots and D-shell connectors are types of PhysicalConnectors.' SUP cim22PhysicalElement MAY (cimConnectorPinout $ cimConnectorType) Expires 6/30/00 [Page 33]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ) The following content rule specifies the auxiliary classes that may be attached to cim22PhysicalConnector. ( <oid-oc77> NAME 'cim22PhysicalConnectorContentRule' DESC 'The auxiliary classes that may be attached to cim22PhysicalConnector' AUX (cim22ConnectedToAuxClass $ cim22PackageInConnectorAuxClass $ cim22LinkHasConnectorAuxClass $ cim22ConnectorOnPackageAuxClass $ cim22AdapterActiveConnectionAuxClass $ cim22RealizesAuxClass $ cim22ProductPhysicalElementsAuxClass $ cim22FRUPhysicalElementsAuxClass $ cim22PhysicalElementLocationAuxClass $ cim22ElementCapacityAuxClass $ cim22ParticipatesInSetAuxClass $ cim22ContainerAuxClass $ cim22ElementsLinkedAuxClass $ cim22CollectedMSEsAuxClass $ cim22ElementConfigurationAuxClass $ cim22ElementSettingAuxClass $ cim22DependencyAuxClass $ cim22ProvidesServiceToElementAuxClass $ cim22ComponentAuxClass $ cim22SystemComponentAuxClass) ) 3.33 cim22ConnectedToAuxClass This class shows that two or more physical connectors are connected. ( <oid-oc78> NAME 'cim22ConnectedToAuxClass' DESC 'The ConnectedTo association indicates that two or more PhysicalConnectors are connected together. Both attributes point to cim22PhysicalConnector objects.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.34 cim22Slot A slot represents connectors into which packages are inserted. For example, a physical package that is a disk drive may be inserted into a SCA slot. As another example, a card may be inserted into a 16-, 32-, or 64-bit expansion slot on a hosting board. ( <oid-at154> NAME 'cimSupportsHotPlug' DESC 'Boolean indicating whether the Slot supports hot-plug of adapter Cards.' SYNTAX boolean SINGLE-VALUE ) Expires 6/30/00 [Page 34]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 ( <oid-at155> NAME 'cimHeightAllowed' DESC 'Maximum height of an adapter Card that can be inserted into the Slot, in inches./ SUP cim22Float32 SINGLE-VALUE ) ( <oid-at156> NAME 'cimLengthAllowed' DESC 'Maximum length of an adapter Card that can be inserted into the Slot, in inches.' SUP cim22Float32 SINGLE-VALUE ) ( <oid-at157> NAME 'cimMaxDataWidth' DESC 'Maximum bus width of adapter Cards that can be inserted into this Slot, in bits. If the value is "unknown", enter 0. If the value is other than 8, 16, 32, 64 or 128, enter 1.' SYNTAX integer SINGLE-VALUE ) ( <oid-at158> NAME 'cimVccMixedVoltageSupport' DESC 'An array of enumerated integers indicating the Vcc voltage supported by this Slot.' SYNTAX integer ) ( <oid-at159> NAME 'cimVppMixedVoltageSupport' DESC 'An array of enumerated integers indicating the Vpp voltage supported by this Slot.' SYNTAX integer ) ( <oid-at160> NAME 'cimThermalRating' DESC 'Maximum thermal dissipation of the Slot in milliwatts.' SYNTAX integer SINGLE-VALUE ) ( <oid-at161> NAME 'cimSpecialPurpose' DESC 'Boolean indicating that this Slot is physically unique and may hold special types of hardware, e.g. a graphics processor slot. If set to TRUE, then the property, SpecialPurposeDescription (a string), should specify the nature of the uniqueness or purpose of the Slot.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at162> NAME 'cimPurposeDescription' DESC 'A free-form string describing that this Slot is physically Expires 6/30/00 [Page 35]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 unique and may hold special types of hardware. This property only has meaning when the corresponding boolean property, SpecialPurpose, is set to TRUE.' SYNTAX string SINGLE-VALUE ) ( <oid-at163> NAME 'cimNumber' DESC 'The Number property indicates the physical slot number, which can be used as an index into a system slot table, whether or not that slot is physically occupied.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc79> NAME 'cim22Slot' DESC 'The Slot class represents Connectors into which Packages are inserted. For example, a PhysicalPackage that is a DiskDrive may be inserted into an SCA "Slot". As another example, a Card (subclass of PhysicalPackage) may be inserted into a 16-, 32-, or 64-bit expansion "Slot" on a HostingBoard. PCI or PCMCIA Type III Slots are examples of the latter.' SUP cim22PhysicalConnector MAY (cimSupportsHotPlug $ cimHeightAllowed $ cimLengthAllowed $ cimMaxDataWidth $ cimThermalRating $ cimVccMixedVoltageSupport $ cimVppMixedVoltageSupport $ cimSpecialPurpose $ cimPurposeDescription $ cimNumber) ) The following content rule specifies the auxiliary classes that may be attached to cim22Slot. ( <oid-oc79> NAME 'cim22SlotContentRule' DESC 'The auxiliary classes that may be attached to cim22Slot' AUX (cim22SlotInSlotAuxClass $ cim22AdjacentSlotsAuxClass $ cim22PackageInSlotAuxClass $ cim22CardInSlotAuxClass) ) 3.35 cim22SlotInSlotAuxClass This class represents the ability of an adapter to extend a slot structure, which enables the slot to support cards that would otherwise be incompatible by interfacing to the slot provided by the adapter. This has many practical uses. ( <oid-oc80> NAME 'cim22SlotInSlotAuxClass' DESC 'Slots are special types of Connectors into which adapter Cards are typically inserted. The SlotInSlot relationship represents the ability of a special adapter to extend the Expires 6/30/00 [Page 36]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 existing Slot structure to enable otherwise incompatible Cards to be plugged into a Frame or HostingBoard. The adapter effectively creates a new Slot and can be thought of (conceptually) as a Slot in a Slot. This enables Cards that would otherwise be physically and/or electrically incompatible with the existing Slots to be supported, by interfacing to the Slot provided by the adapter. This has many practical uses. For example, networking boards are very expensive. As new hardware becomes available, Chassis and even Card configurations change. To protect the investment of their customers, networking vendors will manufacture special adapters that enable old Cards to fit into new Chassis or HostingBoards and/or new Cards to fit into old. This is done using a special adapter that fits over one or more existing Slots and presents a new Slot into which the Card can plug. Both attributes point to cim22Slot objects.' SUP cim22ConnectedToAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.36 cim22AdjacentSlotsAuxClass This class describes the layout of slots on a hosting board or adapter card and includes the distance between the slots and whether they are 'shared'. ( <oid-at164> NAME 'cimSlotARef' DESC 'One of the adjacent Slots.' SYNTAX DN ) ( <oid-at165> NAME 'cimSlotBRef' DESC 'The "other" adjacent Slot.' SYNTAX DN ) ( <oid-at166> NAME 'cimDistanceBetweenSlots' DESC 'The distance, in inches, between adjacent Slots.' SUP cim22Float32 SINGLE-VALUE ) ( <oid-at167> NAME 'cimSharedSlots' DESC 'Slots can be located in close proximity on Hosting Boards or other Cards, such that if one of these Slots is populated by an adapter Card, the other Slot must be left empty. This relationship is indicated by the SharedSlots boolean set to TRUE.' Expires 6/30/00 [Page 37]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 SYNTAX boolean SINGLE-VALUE ) ( <oid-oc81> NAME 'cim22AdjacentSlotsAuxClass' DESC 'AdjacentSlots describes the layout of Slots on a HostingBoard or adapter Card. Information like the distance between the Slots and whether they are "shared" (if one is populated, then the other Slot can not be used), is conveyed as properties of the association. Both reference attributes point to cim22Slot objects.' SUP top AUXILIARY MAY (cimSlotARef $ cimSlotBRef $ cimDistanceBetweenSlots $ cimSharedSlots) ) 3.37 cim22PackageInConnectorAuxClass This class represents the relationship between cards that are into system connectors for power and/or to transfer data. For example, it would be used to describe the insertion of a daughter card onto another card. ( <oid-oc82> NAME 'cim22PackageInConnectorAuxClass' DESC 'Adapter cards and other "packaging" are plugged into System Connectors for power and/or to transfer data. This relationship is defined by PackageInConnector. For example, it would be used to describe the insertion of a daughtercard onto another Card. Various subclasses of PackageInConnector are also defined. PackageInSlot and its subclass, CardInSlot, are two examples of subclasses. Attribute cimAntecedentRef points to cim22PhysicalConnector and attribute cimDependentRef points to cim22PhysicalPackage.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.38 cim22PackageInSlotAuxClass Complex networking devices often are based on chassis, which allow for enhancement and/or augmentation of their base functionality adding new chassis devices, similar to adding cards. This auxiliary class models this capability. ( <oid-oc83> NAME 'cim22PackageInSlotAuxClass' DESC 'Complex networking devices often are Chassis-based. These Chassis allow for enhancement and/or augmentation of their base functionality by accepting additional Chassis devices, Expires 6/30/00 [Page 38]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 similar to accepting functionality in the form of adding Cards. This association models this capability.. Attribute cimAntecedentRef points to cim22Slot and attribute cimDependentRef points to cim22PhysicalPackage.' SUP cim22PackageInConnectorAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.39 cim22CardInSlotAuxClass Slots are special types of connectors into which cards are inserted. This relationship of a Card in a Slot is made explicit using this class. ( <oid-oc84> NAME 'cim22CardInSlotAuxClass' DESC 'Slots are special types of Connectors into which adapter Cards are inserted. This relationship of a Card in a Slot is made explicit using the CardInSlot association. Attribute cimAntecedentRef points to cim22Slot and attribute cimDependentRef points to cim22Card.' SUP cim22PackageInSlotAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.40 cim22LinkHasConnectorAuxClass Cables and links use physical connectors to connect physical elements, which this class explicitly defines. ( <oid-oc85> NAME 'cim22LinkHasConnectorAuxClass' DESC 'Cables and Links utilize PhysicalConnectors to actually "connect" PhysicalElements. This association explicitly defines this relationship of Connectors for PhysicalLinks. Attribute cimGroupComponentRef points to cim22PhysicalLink and attribute cimPartComponentRef points to cim22PhysicalConnector.' SUP cim22ComponentAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef) ) 3.41 cim22ConnectorOnPackageAuxClass Physical packages contain connectors and other physical elements, which this class makes explicit. ( <oid-oc86> NAME 'cim22ConnectorOnPackageAuxClass' DESC 'PhysicalPackages contain Connectors as well as other PhysicalElements. The ConnectorOnPackage association makes Expires 6/30/00 [Page 39]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 explicit the containment relationship between Connectors and Packages. Attribute cimGroupComponentRef points to cim22PhysicalPackage and attribute cimPartComponentRef points to cim22PhysicalConnector.' SUP cim22ContainerAuxClass AUXILIARY MAY (cimGroupComponentRef $ cimPartComponentRef $ cimLocationWithinContainer) ) 3.42 cim22AdapterActiveConnectionAuxClass This class shows that a network adapter uses a physical connector for output to the network. This relationship is important when the adapter can choose from one of several connectors. ( <oid-oc87> NAME 'cim22AdapterActiveConnectionAuxClass' DESC 'The AdapterActiveConnection relationship indicates that a NetworkAdapter is using the referenced PhysicalConnector to output to the network. This relationship is important when the Adapter can choose to output from one of several Connectors. The Connectors may be associated with the NetworkAdapter in a Realizes relationship - but this is not required. This association provides additional information (i.e., "in use for communication") different than Realizes. Attribute cimAntecedentRef points to cim22PhysicalConnector and attribute cimDependentRef points to cim22NetworkAdapter.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.43 cim22ComputerSystemPackageAuxClass Similar to the way that physical element 'realize' logical devices, physical packages 'realize' unitary computer systems. This class explicitly defines this relationship. ( <oid-at168> NAME 'cimPlatformGUID' DESC 'A Gloabally Unique Identifier for the System's Package.' SYNTAX string SINGLE-VALUE ) ( <oid-oc88> NAME 'cim22ComputerSystemPackageAuxClass' DESC 'Similar to the way that LogicalDevices are "Realized" by PhysicalElements, UnitaryComputerSystems are realized in one or more PhysicalPackages. The ComputerSystemPackage association explicitly defines this relationship. Attribute cimAntecedentRef points to cim22PhysicalPackage and attribute Expires 6/30/00 [Page 40]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 cimDependentRef points to cim22UnitaryComputerSystem.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef $ cimPlatformGUID) ) 3.44 cim22LibraryPackageAuxClass Similar to the way that physical element 'realize' logical devices, physical packages 'realize' storage libraries. This class explicitly defines this relationship. ( <oid-oc89> NAME 'cim22LibraryPackageAuxClass' DESC 'Similar to the way that LogicalDevices are "Realized" by PhysicalElements, a StorageLibrary can be realized in one or more PhysicalPackages. The LibraryPackage association explicitly defines this relationship. Attribute cimAntecedentRef points to cim22PhysicalPackage and attribute cimDependentRef points to cim22StorageLibrary.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.45 cim22PackageCoolingAuxClass Often, a package includes a cooling device to assist in the cooling of the Package in general. This relationship is described by this class. ( <oid-oc90> NAME 'cim22PackageCoolingAuxClass' DESC 'Often, a CoolingDevice is installed in a Package such as a Chassis or a Rack, not for a specific Device, but to assist in the cooling of the Package in general. This relationship is described by the PackageCooling association. Attribute cimAntecedentRef points to cim22CoolingDevice. Attribute cimDependentRef points to cim22PhysicalPackage.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 3.46 cim22PackageAlarmAuxClass Often, an alarm device is installed as part of a package, not to track any particular logical device or physical component, but the package itself. This relationship is described by this class. ( <oid-oc91> NAME 'cim22PackageAlarmAuxClass' DESC 'Often, an AlarmDevice is installed as part of a Package, not to indicate issues with any particular LogicalDevice or Expires 6/30/00 [Page 41]
INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember 1999 PhysicalComponent, but with the Package's environment in general, its security state or its overall health. This relationship is described by the PackageAlarm association. Attribute cimAntecedentRef points to cim22AlarmDevice and attribute cimDependentRef points to cim22PhysicalPackage.' SUP cim22DependencyAuxClass AUXILIARY MAY (cimAntecedentRef $ cimDependentRef) ) 4. References Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites. [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)," RFC 2251, Decemeber 1997. [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Light- weight Directory Access Protocol (v3): Attribute Syntax Definitions," RFC 2252, December 1997. [3] Ryan Moats, Gerald Maziarski, John Strassner, "Extensible Match Rule to Dereference Pointers", Internet Draft (work in progress), June 1999. [4] DMTF, "CIM Physcial Model, v2.2". [5] Ryan Moats, Gerald Maziarski, John Strassner, "LDAP Schema for the DMTF Core CIM v2.2 Model", Internet Draft (work in progress), December 1999. [6] Doug Wood, "Directory string representation for floating point values", Internet Draft (work in progress), December 1999. 5. Author's Addresses Ryan Moats Jerry Maziarski John Strassner 15621 Drexel Circle Room C3-3Z01 Cisco Systems, Bldg 1 Omaha, NE 68135 200 S. Laurel Ave. 170 West Tasman Drive USA Middletown, NJ 07748 San Jose, CA 95134 E-mail: jayhawk@att.com USA E-mail: johns@cisco.com E-mail: gfm@qsun.att.com Expires 6/30/00 [Page 42]