Internet-Draft                                                Ryan Moats
draft-moats-dmtf-physical-ldap-00.txt
draft-moats-dmtf-physical-ldap-01.txt                   Gerald Maziarski
Expires in six months                                               AT&T
                                                          John Strassner
                                                           cisco Systems
                                                            October
                                                           December 1999

            LDAP Schema for the DMTF Physical CIM v2.2 Model
            Filename: draft-moats-dmtf-physical-ldap-00.txt 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.

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

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
      )

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

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'

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

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

   no TemperatureSensors in the schema.

2.1 dmtfLocation

3.1 cim22Location

   Locations are the position and address of a PhysicalElement.  This
   class reuses the name attribute and defines the attributes
   physicalPosition and address.

      ( <oid-at462> <oid-at76> NAME 'physicalPosition' 'cimPhysicalPosition'
        DESC 'Position is a free-form string indicating the placement of
           a
              PhysicalElement. It can specify slot information on a
              HostingBoard, mounting site in a Cabinet, or latitude and
              longitude information, for example, from a GPS. May be used
           as an RDN.' It is part
              of the key of the Location object.'
        SYNTAX string{256} SINGLE-VALUE
      )

      ( <oid-at463> <oid-at77> NAME 'address' '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-oc185> <oid-oc46> NAME 'dmtfLocation' 'cim22Location'
        DESC 'specifies 'The Location class specifies the position and address of a
              PhysicalElement.'
        SUP top
        MUST (name (orderedCimModelPath $ physicalPosition cimName $ address) cimPhysicalPosition)
        MAY (cimAddress)
      )

2.2 dmtfPhysicalElementLocationAuxClass

      ( <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)
      )

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

3.2 cim22PhysicalElementLocationAuxClass

   This class associates a physical element with a dmtfLocation cim22Location object.
   It defines the attributes dmtfPhysicalElementRefs and
   dmtfLocationRef.

      ( <oid-at464> NAME 'dmtfPhysicalElementRefs'
        DESC 'The PhysicalElement whose Location is specified.  May be
           used as an RDN.'
        SYNTAX DN
      )

      ( <oid-at465> <oid-at78> NAME 'dmtfLocationRef' 'cimPhysicalLocationRef'
        DESC 'The Physical Element's Location.  May be used as an RDN.' PhysicalElement's Location.'
        SYNTAX DN SINGLE-VALUE
      )

      ( <oid-oc186> <oid-oc47> NAME 'dmtfPhysicalElementLocationAuxClass' 'cim22PhysicalElementLocationAuxClass'
        DESC 'associates 'PhysicalElementLocation associates a PhysicalElement with a
              Location object for inventory or replacement purposes.'
              purposes. Attribute cimElementRef points to
             cim22PhysicalElement and attribute cimPhysicalLocationRef
points
             to cim22Location. '
        SUP top AUXILIARY
        MUST (dmtfPhysicalElementRefs
        MAY (cimElementRef $ dmtfLocationRef) cimPhysicalLocationRef)
      )

2.3 dmtfPhysicalCapacity

3.3 cim22PhysicalCapacity

   This class describes a physical element's requirements.  It reuses
   the attributes name, caption, and description.

      ( <oid-oc187> <oid-oc48> NAME 'dmtfPhysicalCapacity' 'cim22PhysicalCapacity'
        DESC 'abstract 'PhysicalCapacity is an abstract class describing a
               PhysicalElement's minimum/maximum requirements and
               ability to support different types of hardware.' hardware. For
               example, minimum and maximum memory requirements can be
               modeled as a subclass of cim22PhysicalCapacity.'
        SUP top ABSTRACT
        MUST (name
        MAY (cimName $ caption cimCaption $ description) cimDescription)
      )

2.4 dmtfElementCapacityAuxClass

3.4 cim22ElementCapacityAuxClass

   This class associates a dmtfPhysicalCapacity cim22PhysicalCapacity object with one or more
   dmtfPhysicalElements.  It defines the attributes
   dmtfPhysicalCapacityRefs and dmtfPhysicalElementRefs.
   cim22PhysicalElements.

      ( <oid-at466> <oid-at79> NAME 'dmtfPhysicalCapacityRefs' 'cimCapacityRef'
        DESC 'PhysicalCapacity describes the minimum and maximum
              requirements, and ability to support different types of
              hardware for a PhysicalElement.  May be used as an RDN.'
        SYNTAX DN
      )

      ( <oid-at467> NAME 'dmtfPhysicalElementRefs'
        DESC 'The PhysicalElement being described.  May be used as an
           RDN.' PhysicalElement.'
        SYNTAX DN
      )

      ( <oid-oc188> <oid-oc49> NAME 'dmtfElementCapacityAuxClass' 'cim22ElementCapacityAuxClass'
        DESC 'associates 'ElementCapacity associates a PhysicalCapacity object with
              one or more
           PhysicalElements.' PhysicalElements. It serves to associate a

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
        MUST (dmtfPhysicalCapacityRefs
        MAY (cimCapacityRef $ dmtfPhysicalElementRefs) cimElementRef)
      )

2.5 dmtfMemoryCapacity

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.  It defines the attributes memoryType,
   minimumMemoryCapacity, and maximumMemoryCapacity.

      ( <oid-at468> <oid-at80> NAME 'memoryType' '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.  May be used as an RDN.
           Allowed values are: "Unknown", "Other", "DRAM",
           "Synchronous DRAM", "Cache DRAM", "EDO", "EDRAM", "VRAM",
           "SRAM", "RAM", "ROM", "Flash", "EEPROM", "FEPROM", "EPROM",
           "CDRAM", "3DRAM", "SDRAM", "SGRAM", "RDRAM".' class.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at469> <oid-at81> NAME 'minimumMemoryCapacity' 'cimMinimumMemoryCapacity'
        DESC 'Minimum amount of memory, in Kbytes, that is needed for
              the associated PhysicalElement to operate correctly.' correctly.
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at470> <oid-at82> NAME 'maximumMemoryCapacity' 'cimMaximumMemoryCapacity'
        DESC 'Maximum amount of memory, in Kbytes, that can be supported
              by the associated PhysicalElement.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-oc189> <oid-oc50> NAME 'dmtfMemoryCapacity' 'cim22MemoryCapacity'
        DESC 'describes 'MemoryCapacity describes the type of Memory that can be
              installed on a PhysicalElement and its minimum/maximum configurations.'
              configurations. Information on what memory is currently
              "installed", versus an Element's min/max requirements, is
              located in instances of the PhysicalMemory class.'
        SUP dmtfPhysicalCapacity cim22PhysicalCapacity
        MUST (memoryType (orderedCimModelPath $ minimumMemoryCapacity cimMemoryType)
        MAY (cimMinimumMemoryCapacity $ maximumMemoryCapacity) cimMaximumMemoryCapacity)
      )

2.6 dmtfConfigurationCapacity

      ( <oid-nf13> NAME 'cim22MemoryCapacityNameForm'
        OC cim22MemoryCapacity
        MUST (orderedCimModelPath)

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).
   DmtfElementCapacityAuxClass indentifies
   cim22ElementCapacityAuxClass identifies the physical element whose
   configuration is described.  The attribute objectType identifies the
   object (ie, the power supply or fan) whose capacities are 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.  it reuses the
   attribute otherTypeDescription and defines objectType,
   minimumCapacity, maximumCapacity, and increment.

      ( <oid-at471> <oid-at83> NAME 'objectType' 'cimObjectType'
        DESC 'The type of object (power supply, fan, disk drive, ..) ...)
              whose capacities are shown. May be used as an RDN.' indicated. This information is part of
              the class' key.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at472> <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 'minimumCapacity' 'cimMinimumCapacity'
        DESC 'Minimum number of Elements of type, ObjectType, that must
              be installed.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at473> <oid-at86> NAME 'maximumCapacity' 'cimMaximumCapacity'
        DESC 'Maximum number of Elements of type, ObjectType, that may be
              installed.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at474> <oid-at87> NAME 'increment' 'cimIncrement'

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-oc190> <oid-oc51> NAME 'dmtfConfigurationCapacity' '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).' 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 dmtfPhysicalCapacity cim22PhysicalCapacity
        MUST (objectType (orderedCimModelPath $ otherTypeDescription cimObjectType)
        MAY (cimOtherTypeDescription $ minimumCapacity cimMinimumCapacity $
           maximumCapacity
             cimMaximumCapacity $ increment) cimIncrement)
      )

      ( <oid-nf14> NAME 'cim22ConfigurationCapacityNameForm'
        OC cim22ConfigurationCapacity
        MUST (orderedCimModelPath)
      )

      ( <sr14> NAME 'cim22ConfigurationCapacityStructureRule'
        FORM cim22ConfigurationCapacityNameForm
      )

2.7 dmtfReplacementSet

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.  It reuses the attributes name and description.

      ( <oid-oc191> <oid-oc52> NAME 'dmtfReplacementSet' 'cim22ReplacementSet'
        DESC 'The ReplacementSet class aggregates PhysicalElements that
              must be "replaced" or "FRUed" together.' 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 (name (cimName $ description) orderedCimModelPath)
        MAY (cimDescription)
      )

2.8 dmtfParticipatesInSetAuxClass

   This class shows which physical elements should be replaced together.
   It defines the attributes dmtfReplacementSetRefs and
   dmtfPhysicalElementRefs.

      ( <oid-at475> <oid-nf15> NAME 'dmtfReplacementSetRefs'
        DESC 'The ReplacementSet.'
        SYNTAX DN '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-at476> <oid-oc52> NAME 'dmtfPhysicalElementRefs' 'cim22ReplacementSetContentRule'
        DESC 'The PhysicalElement auxiliary classes that may be attached to
              cim22ReplacementSet'
        AUX (cim22ParticipatesInSetAuxClass)
      )

3.8 cim22ParticipatesInSetAuxClass

   This class shows which physical elements should be replaced with other
           Elements, as a Set.'
        SYNTAX DN
      ) together.

      ( <oid-oc192> <oid-oc53> NAME 'dmtfParticipatesInSetAuxClass' 'cim22ParticipatesInSetAuxClass'
        DESC 'shows 'ParticipatesInSet indicates which PhysicalElements should
              be replaced
           together.' together. Attribute cimSetRef points to
              cim22ReplacementSet and attribute cimElementRef points to
              cim22PhysicalElement.'
        SUP top AUXILIARY
        MUST (dmtfReplacementSetRefs
        MAY (cimSetRef $ dmtfPhysicalElementRefs) cimElementRef)

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      )

2.9 dmtfPhysicalPackage

3.9 cim22PhysicalPackage

   A physical package contains or hosts components. Examples are a rack
   enclosure or an adapter Card.

      ( <oid-at477> <oid-at89> NAME 'removable' 'cimRemovable'
        DESC 'An object '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 Component Package can still be Removable if
              power must be "off" in order to perform the removal. If
              power can be "on" and the Component Package removed, then the Element
              is both Removable and HotSwappable. For example, an upgradeable
           Processor chip extra
              battery in a laptop is Removable, as is a disk drive
              Package inserted using SCA connectors. However, the latter
              is Removable.' 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-at478> <oid-at90> NAME 'replaceable' 'cimReplaceable'
        DESC 'An object '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. Here, In this case, the Processor is said to be
              Replaceable. Another example is a power supply Package
              mounted on sliding rails. All Removable Components packages are
              inherently Replaceable.'
        SYNTAX boolean SINGLE-VALUE
      )

      ( <oid-at479> <oid-at91> NAME 'hotSwappable' 'cimHotSwappable'
        DESC 'An object '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". "on"). For example, a fan
           Component may be designed to be disk drive
              Package inserted using SCA connectors is both Removable and
              HotSwappable. All HotSwappable Components packages are inherently
              Removable and Replaceable.'
        SYNTAX boolean SINGLE-VALUE
      )

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      ( <oid-at480> <oid-at92> NAME 'height' 'cimHeight'
        DESC 'The height of the object.'
        SYNTAX binary PhysicalPackage in inches.'
        SUP CimFloat32 SINGLE-VALUE
      )

      ( <oid-at481> <oid-at93> NAME 'depth' 'cimDepth'
        DESC 'The depth of the object.'
        SYNTAX binary PhysicalPackage in inches.'
        SUP CimFloat32 SINGLE-VALUE
      )

      ( <oid-at482> <oid-at94> NAME 'width' 'cimWidth'
        DESC 'The width of the object.'
        SYNTAX binary PhysicalPackage in inches.'
        SUp CimFloat32 SINGLE-VALUE
      )

      ( <oid-at483> <oid-at95> NAME 'weight' 'cimWeight'
        DESC 'The weight of the object.'
        SYNTAX binary PhysicalPackage in pounds.'
        SUP CimFloat32 SINGLE-VALUE
      )

      ( <oid-oc193> <oid-oc54> NAME 'dmtfPhysicalPackage' 'cim22PhysicalPackage'
        DESC 'The PhysicalPackage class represents PhysicalElements that
              contain or host other components.' components. Examples are a Rack
              enclosure or an adapter Card.'
        SUP dmtfPhysicalElement cim22PhysicalElement
        MAY (cimRemovable $ cimReplaceable $ cimHotSwappable $
             cimHeight $ cimDepth $ cimWidth $ cimWeight)
      )

      ( <oid-nf16> NAME 'cim22PhysicalPackageNameForm'
        OC cim22PhysicalPackage
        MUST (removable (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 $ replaceable cim22PackageInChassisAuxClass $ hotSwappable
             cim22PackagedComponentAuxClass $ height
             cim22PackageInConnectorAuxClass $ depth
             cim22PackageInSlotAuxClass $
           width cim22ConnectorOnPackageAuxClass $

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

             cim22ComputerSystemPackageAuxClass $
             cim22LibraryPackageAuxClass $ cim22PackageCoolingAuxClass $
             cim22PackageTempSensorAuxClass $ cim22PackageAlarmAuxClass $
             cim22ProductPhysicalElementsAuxClass $
             cim22FRUPhysicalElementsAuxClass $
             cim22PhysicalElementLocationAuxClass $ weight)
             cim22ElementCapacityAuxClass $
             cim22ParticipatesInSetAuxClass $ cim22ElementsLinkedAuxClass $
             cim22CollectedMSEsAuxClass $
             cim22ElementConfigurationAuxClass $
             cim22ElementSettingAuxClass $ cim22DependencyAuxClass $
             cim22ProvidesServiceToElementAuxClass $
             cim22ComponentAuxClass $ cim22SystemComponentAuxClass)
      )

2.10 dmtfContainerAuxClass

3.10 cim22ContainerAuxClass

   This class represents the relationship between a contained and a
   containing PhysicalElement.  In it, groupComponentRef must point to a
   dmtfPhysicalPackageObject and partComponentRefs must point to a
   dmtfPhysicalElementObject.  Further, it defines the attribute
   locationWithinContainer.

      ( <oid-at484> NAME 'groupComponentRef'
        DESC 'The PhysicalPackage that contains other PhysicalElements,
           including other Packages.'
        SYNTAX DN SINGLE-VALUE
      )

      ( <oid-at485> <oid-at96> NAME 'locationWithinContainer' '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
           dmtfLocation
              cimLocation object.'
        SYNTAX string SINGLE-VALUE
      )

      ( <oid-oc194> <oid-oc55> NAME 'dmtfContainerAuxClass' 'cim22ContainerAuxClass'
        DESC 'The Container association represents the relationship
              between a contained and a containing PhysicalElement.' PhysicalElement. A
              containing object must be a PhysicalPackage. Attribute
              cimGroupComponentRef points to cim22PhysicalPackage and
              attribute cimPartComponentRef points to
              cim22PhysicalElement.'
        SUP dmtfComponentAuxClass cim22ComponentAuxClass AUXILIARY
        MUST (groupComponentRef
        MAY (cimGroupComponentRef $ cimPartComponentRef $ locationWithinContainer)
             cimLocationWithinContainer)
      )

2.11 dmtfPhysicalFrame

3.11 cim22PhysicalFrame

   A physical frame is a generic frame enclosure.

      ( <oid-at486> <oid-at97> NAME 'cableManagementStrategy' '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,

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 task. endeavor. This string property
              contains information to aid in assembly and service of the
              Frame.'
        SYNTAX string SINGLE-VALUE
      )

      ( <oid-at487> <oid-at100> NAME 'servicePhilosophy' 'cimLockPresent'
        DESC 'ServicePhilosophy is an enumerated, integer-valued array
           that shows 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 'Boolean indicating whether the Frame is moveable (8), for example, having rollers.
           Allowed values are: "Unknown", "Other", "Service From Top"
           "Service From Front", "Service From Back", "Service From
           Side", "Sliding Trays", "Removable Sides", "Moveable".' protected with a
              lock.'
        SYNTAX integer boolean SINGLE-VALUE
      )

      ( <oid-at488> <oid-at101> NAME 'serviceDescriptions' 'cimAudibleAlarm'
        DESC 'An array of free-form strings providing more detailed
           explanations for any of the entries in 'Boolean indicating whether the
           ServicePhilosophy array.' Frame is equipped with an
              audible alarm.'
        SYNTAX string boolean SINGLE-VALUE
      )

      ( <oid-at489> <oid-at102> NAME 'lockPresent' 'cimVisibleAlarm'
        DESC 'Boolean indicating whether that the Frame is protected with equipment includes a
           lock.' visible
              alarm.'
        SYNTAX boolean SINGLE-VALUE
      )

      ( <oid-at490> <oid-at103> NAME 'securityBreach' '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" "Unknown", "Other" or
              "No Breach".' Breach", can be specified.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at491> <oid-at104> NAME 'breachDescription' 'cimBreachDescription'
        DESC 'BreachDescription is a free-form string providing more
              information if the SecurityBreach property shows indicates that a
              breach or some other security-related event occurred.'
        SYNTAX string SINGLE-VALUE
      )

      ( <oid-oc195> <oid-at105> NAME 'dmtfPhysicalFrame' 'cimIsLocked'
        DESC 'PhysicalFrame 'Boolean indicating that the Frame is a superclass of Rack, Chassis and other
           frame enclosures, as they are defined in extension
           classes.' currently locked.'
        SYNTAX boolean SINGLE-VALUE
      )

      ( <oid-oc56> NAME 'cim22PhysicalFrame'
        SUP  dmtfPhysicalPackage
        MUST (cableManagementStrategy $ servicePhilosophy $
           serviceDescriptions cim22PhysicalPackage

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

        MAY (cimCableManagementStrategy $ lockPresent cimLockPresent $ audibleAlarm
             cimAudibleAlarm $
           visibleAlarm cimVisibleAlarm $ securityBreach cimSecurityBreach $ breachDescription
             cimBreachDescription $
           isLocked) cimIsLocked)
      )

      ( <oid-nf17> NAME 'cim22PhysicalFrameNameForm'
        OC cim22PhysicalFrame
        MUST (orderedCimModelPath)
      )

2.12 dmtfRack

      ( <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.  This class reuses the attribute height and
   defines the attributes typeOfRack and countryDesignation.

      ( <oid-at492> <oid-at106> NAME 'typeOfRack' 'cimTypeOfRack'
        DESC 'Enumeration indicating the type of Rack. Specifies
           information  Information such
              as "Telco" rack (value=2) or standard 19 inch rack (1).
           Allowed values are: "Unknown", "Standard 19 Inch", "Telco",
           "Equipment Shelf", "Non-Standard".' (1) can
              be specified. The country for which the Rack is
              manufactured is defined in the the CountryDesignation
              property.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at493> <oid-at107> NAME 'countryDesignation' 'cimCountryDesignation'
        DESC 'Country 'Designation of the country for which the Rack is
              designed. ISO/IEC 3166
           defines country Country code strings.' strings are as defined by ISO/IEC
              3166. The rack type is specified in the TypeOfRack
              property.'
        SYNTAX string SINGLE-VALUE
      )

      ( <oid-oc196> <oid-oc57> NAME 'dmtfRack' 'cim22Rack'
        DESC 'A Rack is a PhysicalFrame that represents an enclosure in
              which Chassis are placed.' 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 dmtfPhysicalFrame
        MUST (height $ typeOfRack cim22PhysicalFrame
        MAY (cimTypeOfRack $ countryDesignation) cimCountryDesignation)
      )

   The following content rule specifies the auxiliary classes that may
   be attached to cim22Rack.

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)
      )

2.13 dmtfChassis

3.13 cim22Chassis

   Chassis enclose other elements and provide definable functionality.

      ( <oid-at494> <oid-at108> NAME 'numberOfPowerCords' 'cimNumberOfPowerCords'
        DESC 'Integer indicating the number of power cords that which must be
              connected to the Chassis, for all the componentry to
              operate.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at495> <oid-at109> NAME 'currentRequiredOrProduced' 'cimCurrentRequiredOrProduced'
        DESC 'Current required by the Chassis at 120V. If power is
              provided by the Chassis (as for in the case of a UPS), this
              property may
           be indicate the amperage produced, as a negative
              number.'
        SYNTAX binary integer SINGLE-VALUE
      )

      ( <oid-at496> <oid-at110> NAME 'heatGeneration' 'cimHeatGeneration'
        DESC 'Amount of heat generated by the Chassis in BTU/hour.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at497> NAME 'chassisTypes'
        DESC 'An enumerated, integer-valued array indicating the type of
           Chassis.'
        SYNTAX integer
      )

      ( <oid-at498> NAME 'typeDescriptions'
        DESC 'An array of free-form strings providing more information on
           the ChassisTypes array entries.'
        SYNTAX string
      )

      ( <oid-oc197> <oid-oc58> NAME 'dmtfChassis' '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 dmtfPhysicalFrame
        MUST (numberOfPowerCords cim22PhysicalFrame
        MAY (cimNumberOfPowerCords $ currentRequiredOrProduced cimCurrentRequiredOrProduced $
           heatGeneration
             cimHeatGeneration)
      )

      ( <oid-nf18> NAME 'cim22ChassisNameForm'
        OC cim22Chassis
        MUST (orderedCimModelPath)
      )

      ( <sr18> NAME 'cim22ChassisStructureRule'
        FORM cim22ChassisNameForm
      )

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 $ chassisTypes cim22PackageInChassisAuxClass $ typeDescriptions)
             cim22DockedAuxClass)
      )

2.14 dmtfChassisInRackAuxClass

3.14 cim22ChassisInRackAuxClass

   This class makes explicit the 'containing' relationship between the
   Rack and the Chassis.  In it, groupComponentRef points to a single
   dmtfRack object while partComponentRefs point to dmtfChassis object.
   The attribute bottomU is also defined.

      ( <oid-at499> <oid-at113> NAME 'bottomU' 'cimBottomU'
        DESC 'An integer indicating the lowest or 'bottom' "bottom" U in which the
              Chassis is mounted. A 'U' "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-oc198> <oid-oc59> NAME 'dmtfChassisInRackAuxClass' 'cim22ChassisInRackAuxClass'
        DESC 'makes '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.' Chassis.Attribute cimGroupComponentRef points
              to cim22Rack and attribute cimPartComponentRef points to
              cim22Chassis.'
        SUP dmtfContainerAuxClass cim22ContainerAuxClass AUXILIARY
        MUST (bottomU)
        MAY (cimGroupComponentRef $ cimPartComponentRef $
             cimLocationWithinContainer $ cimBottomU)
      )

2.15 dmtfPackageInChassisAuxClass

3.15 cim22PackageInChassisAuxClass

   This class makes the containment relationship between a chassis and
   other packages explicit.  In it, groupComponentRef must point to a
   dmtfChassis object and partComponentRefs must point to
   dmtfPhysicalPackage objects.

      ( <oid-oc199> <oid-oc60> NAME 'dmtfPackageInChassisAuxClass' 'cim22PackageInChassisAuxClass'
        DESC 'A Chassis can contain other Packages, such as other Chassis
              and Cards. The PackageInChassis association makes explicit
              this relationship.' relationship. Attribute cimGroupComponentRef points to
              cim22Chassis and attribute cimPartComponentRef points to
              cim22PhysicalPackage.'
        SUP dmtfContainerAuxClass cim22ContainerAuxClass AUXILIARY
        MAY (cimGroupComponentRef $ cimPartComponentRef $

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

             cimLocationWithinContainer)
      )

2.16 dmtfDockedAuxClass

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.  In it, antecedentRef and dependentRef point to only one
   dmtfChassis object.

      ( <oid-at500> <oid-oc61> NAME 'antecedentRef'
        DESC 'A single object that is dependend on.'
        SYNTAX DN SINGLE-VALUE
      )
      ( <oid-at501> NAME 'dependentRef'
        DESC 'A single dependent object.'
        SYNTAX DN SINGLE-VALUE
      )

      ( <oid-oc200> NAME 'dmtfDockedAuxClass' 'cim22DockedAuxClass'
        DESC 'A laptop, a type of Chassis, may be docked in another type
              of Chassis, a Docking Station.' 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 dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MUST (antecedentRef
        MAY (cimAntecedentRef $ dependentRef) cimDependentRef)
      )

2.17 dmtfCard

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. it defines the attributes hostingBoard, slotLayout,
   requiresDaughterBoard, specialRequirements, requirementsDescription,
   and operatingVoltages.

      ( <oid-at502> <oid-at114> NAME 'hostingBoard' 'cimHostingBoard'
        DESC 'Boolean indicating that this Card is a Motherboard or, more
              generically, a baseboard in a Chassis.'
        SYNTAX boolean SINGLE-VALUE
      )

      ( <oid-at503> <oid-at115> NAME 'slotLayout' '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-at504> <oid-at116> NAME 'requiresDaughterBoard' 'cimRequiresDaughterBoard'
        DESC 'Boolean indicating that at least one daughterboard or
              auxiliary Card is required in order to function properly.'
        SYNTAX boolean SINGLE-VALUE
      )

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      ( <oid-at505> <oid-at117> NAME 'specialRequirements' 'cimSpecialRequirements'
        DESC 'Boolean indicating that this Card is physically unique
              from other Cards of the same type and therefore requires a
              special
           Slot.' 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-at506> <oid-at118> NAME 'requirementsDescription' '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-at507> <oid-at119> NAME 'operatingVoltages' 'cimOperatingVoltages'
        DESC 'Operating voltages required by the Card.'
        SYNTAX binary
      )

      ( <oid-oc201> <oid-oc62> NAME 'dmtfCard' '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.' 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 dmtfPhysicalPackage
        MUST (hostingBoard cim22PhysicalPackage
        MAY (cimHostingBoard $ cimSlotLayout $ cimRequiresDaughterBoard $ slotLayout
             cimSpecialRequirements $ requiresDaughterBoard cimRequirementsDescription $
           specialRequirements
             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 $ requirementsDescription cim22MemoryOnCardAuxClass $
           operatingVoltages)
             cim22CardInSlotAuxClass)

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      )

2.18 dmtfSystemBusCard

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-at508> <oid-at120> NAME 'busType' 'cimBusType'
     DESC 'An enumerated integer describing the System bus type for
           this Card. It shows indicates the type of Slot into which the
           Card can plug. The list of permissible values aligns with
        the System bus types in CIM_PhysicalConnector.ConnectorType.' plug.'
     SYNTAX integer SINGLE-VALUE
   )

   ( <oid-at509> <oid-at121> NAME 'busWidth' '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-oc202> <oid-oc63> NAME 'dmtfSystemBusCard' 'cim22SystemBusCard'
     DESC 'The SystemBusCard class represents additional information
           for a Card, cimCard, detailing the Card's bus type and data width.'
           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 dmtfCard
     MUST (busType cim22Card
     MAY (cimBusType $ busWidth) cimBusWidth)
   )

2.19 dmtfCardOnCardAuxClass

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 and defines the
   mountOrSlotDescription attribute.  In it groupComponentRef points to
   a single dmtfCard object while partComponentRefs also point to
   dmtfCard objects. relationships.

      ( <oid-at510> <oid-at122> NAME 'mountOrSlotDescription' 'cimMountOrSlotDescription'
        DESC 'A string describing and identifying how the Card is mounted
              on or plugged into the "other" Card. This attribute Slot information could
           store slot information, which
              be included in this field and may be enough 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

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-oc203> <oid-oc64> NAME 'dmtfCardOnCardAuxClass' 'cim22CardOnCardAuxClass'
        DESC 'Cards may be plugged into Motherboards/baseboards, are
              daughtercards of an adapter, or support special Card-like
              modules.'
              modules. These relationships are described by the
              CardOnCard association. Both reference attributes point to
              cim22Card objects.'
        SUP dmtfContainerAuxClass cim22ContainerAuxClass AUXILIARY
        MUST (mountOrSlotDescription)
        MAY (cimGroupComponentRef $ cimPartComponentRef $
             cimLocationWithinContainer $ cimMountOrSlotDescription)
      )

2.20 dmtfStorageMediaLocation

3.20 cim22StorageMediaLocation

   A storage media location holds media and goes beyond being just a
   location used by a storage library.

      ( <oid-at511> <oid-at123> NAME 'locationType' 'cimLocationType'
        DESC 'The type of Location. For example, whether this is an
              individual Media "Slot" (value=2), a MediaAccessDevice
              (value=4) or a "Magazine"property.  Allowed
           values are: "Unknown", "Other", "Slot", "Magazine",
           "MediaAccessDevice", "InterLibrary Port", "Limited Access
           Port", "Door", "Shelf", "Vault".' "Magazine" (value=3) is indicated in this
              property.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at512> <oid-at124> NAME 'locationCoordinates' '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-at513> NAME 'mediaTypesSupported'
        DESC 'Certain StorageMediaLocations may only be able to accept a
           limited set of PhysicalMedia MediaTypes.'
        SYNTAX integer
      )

      ( <oid-at514> NAME 'mediaSizesSupported'
        DESC 'The sizes (in inches) of the particular MediaTypes that may
           be placed in the Location'
        SYNTAX binary
      )

      ( <oid-at515> <oid-at127> NAME 'mediaCapacity' 'cimMediaCapacity'
        DESC 'A StorageMediaLocation may hold more than one PhysicalMedia
              - for example, a Magazine. This property shows indicates the
              PhysicalMedia capacity of the Location.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-oc204> <oid-oc65> NAME 'dmtfStorageMediaLocation' 'cim22StorageMediaLocation'
        DESC 'a 'StorageMediaLocation is a PhysicalElement where
              PhysicalMedia may be placed.' placed. This class describes an entity
              that holds Media and is not just a "place" (as is conveyed

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 dmtfPhysicalPackage
        MUST (locationType $ locationCoordinates cim22PhysicalPackage
        MAY (cimLocationType $ mediaTypesSupported cimLocationCoordinates $
           mediaSizesSupported 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 $ mediaCapacity)
             cim22PhysicalMediaInLocationAuxClass)
      )

2.21 dmtfPhysicalComponent

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-oc205> <oid-oc66> NAME 'dmtfPhysicalComponent' 'cim22PhysicalComponent'
        DESC 'represents 'The PhysicalComponent class represents any low-level or
              basic Component within a
           Package.' 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 dmtfPhysicalElement
        MUST (removable cim22PhysicalElement

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

        MAY (cimRemovable $ replaceable cimReplaceable $ hotSwappable) cimHotSwappable)
      )

2.22 dmtfPackagedComponentAuxClass

   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.
   In it, groupComponentRef points to a dmtfPhysicalPackage object and
   partComponentRefs point to dmtfPhysicalComponent objects.

      ( <oid-oc206> <oid-oc67> NAME 'dmtfPackagedComponentAuxClass' 'cim22PackagedComponentAuxClass'
        DESC 'A Component is typically contained by a PhysicalPackage,
              such as a Chassis or Card.' 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 dmtfContainerAuxClass cim22ContainerAuxClass AUXILIARY
        MAY (cimGroupComponentRef $ cimPartComponentRef $
             cimLocationWithinContainer)
      )

2.23 dmtfChip

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-at516> <oid-at128> NAME 'formFactor' 'cimFormFactor'
        DESC 'The implementation form factor for the Chip.For Chip.  For example,
              values such as SIMM (7), TSOP (9) or PGA (10) can be
           specified. Allowed values are: "Unknown", "Other", "SIP",
           "DIP", "ZIP", "SOJ", "Proprietary", "SIMM", "DIMM", "TSOP",
           "PGA", "RIMM", "SODIMM", "SRIMM", "SMD", "SSMP", "QFP",
           "TQFP", "SOIC", "LCC", "PLCC", "BGA", "FPBGA", "LGA".'
              specified.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-oc207> <oid-oc68> NAME 'dmtfChip' 'cim22Chip'
        DESC 'represents 'The Chip class represents any type of integrated circuit
              hardware, including ASICs, processors, memory chips, etc.'
        SUP dmtfPhysicalComponent
        MUST (formFactor) cim22PhysicalComponent
        MAY (cimFormFactor)
      )

2.24 dmtfPhysicalMemory

3.24 cim22PhysicalMemory

   Physical memory are low level memory devices.

      ( <oid-at517> <oid-at129> NAME 'totalWidth' '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-at518> <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 'capacity' 'cimCapacity'
        DESC 'The total capacity of this PhysicalMemory, in bytes.'
        SYNTAX integer SINGLE-VALUE
      )

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      ( <oid-at519> <oid-at133> NAME 'bankLabel' 'cimBankLabel'
        DESC 'A string identifying the physically labeled bank where the
              Memory is located' located - for example, "Bank 0" or "Bank A".'
        SYNTAX string{64} SINGLE-VALUE
      )

      ( <oid-at520> <oid-at134> NAME 'positionInRow' '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 "2"means that this
              Memory is the second device.' device. 0 is an invalid value for this
              property.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at521> <oid-at135> NAME 'interleavePosition' 'cimInterleavePosition'
        DESC 'The position of this PhysicalMemory in an interleave. 0
           for
              indicates non-interleaved. 1 for indicates the first position,
              2 for the second position and so on.' 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-oc208> <oid-oc69> NAME 'dmtfPhysicalMemory' 'cim22PhysicalMemory'
        DESC 'subclass 'PhysicalMemory is a subclass of cim22Chip, representing low
              level memory devices - SIMMS, DIMMs, raw memory chips,
              etc.'
        SUP dmtfChip
        MUST (formFactor cim22Chip
        MAY (cimFormFactor $ memoryType cimMemoryType $ totalWidth cimTotalWidth $ dataWidth
             cimDataWidth $ speed cimSpeed $
           capacity cimCapacity $ bankLabel cimBankLabel $ positionInRow
             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 $ interleavePosition) cim22MemoryWithMediaAuxClass)
      )

2.25 dmtfMemoryOnCardAuxClass

3.25 cim22MemoryOnCardAuxClass

   Hosting boards, adapter Cards, etc., can hold physical memory.
   Therefore, this class represents that relationship.  In it,
   groupComponentRef points to a dmtfCard object while partComponentRefs
   point to dmtfPhysicalMemory objects.

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      ( <oid-oc209> <oid-oc70> NAME 'dmtfMemoryOnCardAuxClass' 'cim22MemoryOnCardAuxClass'
        DESC 'Explicitly 'PhysicalMemory can be located on HostingBoards, adapter
              Cards, etc. This association explicitly defines the this
              relationship of cards containing
           memory.' Memory to Cards.  Attribute
              cimGroupComponentRef points to cim22Card. Attribute
              cimPartComponentRef points to cim22PhysicalMemory.'
        SUP dmtfPackagedComponentAuxClass AUXILIARY cim22PackagedComponentAuxClass
        MAY (cimGroupComponentRef $ cimPartComponentRef $
             cimLocationWithinContainer)
      )

2.26 dmtfPhysicalMedia

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-at522> <oid-at136> NAME 'mediaType' 'cimMediaType'
        DESC 'Specifies the type of the PhysicalMedia, as an enumerated
           integer.'
              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-at523> <oid-at137> NAME 'mediaDescription' 'cimMediaDescription'
        DESC 'Additional detail related to the MediaType enumeration.' 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-at524> <oid-at138> NAME 'writeProtectOn' '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-at525> <oid-at139> NAME 'cleanerMedia' 'cimCleanerMedia'
        DESC 'Boolean indicating that the PhysicalMedia is used for
              cleaning purposes and not data storage.'
        SYNTAX boolean SINGLE-VALUE
      )

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      ( <oid-at526> <oid-at140> NAME 'mediaSize' 'cimMediaSize'
        DESC 'Size of the Media in inches.'
        SYNTAX binary 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-at527> <oid-at141> NAME 'maxMounts' '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-at528> <oid-at142> NAME 'dualSided' '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-at529> NAME 'physicalLabels'
        DESC 'One or more strings on 'labels' on the PhysicalMedia. The
           format of the labels and their state (readable, unreadable,
           upside-down) are shown in the LabelFormats and
           LabelStates array properties.'
        SYNTAX string
      )

      ( <oid-at530> NAME 'labelStates'
        DESC 'An array of enumerated integers describing the states of
           each of the labels on a PhysicalMedia. The Labels
           themselves are listed in the PhysicalLabels property.'
        SYNTAX integer
      )

      ( <oid-at531> <oid-oc71> NAME 'labelFormats' 'cim22PhysicalMedia'
        DESC 'An array of enumerated integers describing the formats of
           each of the labels on a PhysicalMedia. The Labels
           themselves are listed in the PhysicalLabels property.'
        SYNTAX integer
      )

      ( <oid-oc210> NAME 'dmtfPhysicalMedia'
        DESC 'represents 'The PhysicalMedia class represents any type of
              documentation or storage medium, such as tapes, CDROMs, etc.'
              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 dmtfPhysicalComponent
        MUST (capacity cim22PhysicalComponent
        MAY (cimCapacity $ mediaType cimMediaType $ mediaDescription cimMediaDescription $ writeProtectOn
             cimWriteProtectOn $
           cleanerMedia cimCleanerMedia $ mediaSize cimMediaSize $ maxMounts
             cimMaxMounts $
           dualSided cimDualSided $ physicalLabels cimPhysicalLabels $ labelStates
             cimLabelStates $ labelFormats) cimLabelFormats)
      )

2.27 dmtfMemoryWithMediaAuxClass

      ( <oid-nf20> NAME 'cim22PhysicalMemoryNameForm'
        OC cim22PhysicalMemory
        MUST (orderedCimModelPath)
      )

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.  In it, antecedentRefs point to dmtfPhysicalMemory
   objects and dependentRefs point to dmtfPhysicalMedia objects.

      ( <oid-oc211> <oid-oc72> NAME 'dmtfMemoryWithMediaAuxClass' 'cim22MemoryWithMediaAuxClass'
        DESC 'shows 'MemoryWithMedia indicates that Memory is associated with a
              PhysicalMedia and its cartridge.' cartridge. The Memory provides media
              identification and also stores user-specific
              data. Attribute cimAntecedentRef points to
              cim22PhysicalMemory and attribute cimDependentRef points to
              cim22PhysicalMedia.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.28 dmtfPhysicalMediaInLocationAuxClass

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 auxiliary class is
   attached to a dmtfStorageMediaLocation cim22StorageMediaLocation object.  In this class,
   antecedentRef points to a single dmtfStorageMediaLocation object and
   dependentRefs point to dmtfPhysicalMedia objects.

      ( <oid-oc212> <oid-oc73> NAME 'dmtfPhysicalMediaInLocationAuxClass' 'cim22PhysicalMediaInLocationAuxClass'
        DESC 'Within a StorageLibrary, all Media should be accounted for,
              and be present in some Storage Location. This relationship
              is made explicit here' 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 dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MUST (antecedentRef)

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.29 dmtfPhysicalTape

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-at532> <oid-at146> NAME 'tapeLength' 'cimTapeLength'
        DESC 'The physical length of the Tape in feet.'
        SYNTAX binary
        SUP cim22Float32 SINGLE-VALUE
      )

      ( <oid-at533> <oid-at147> NAME 'unloadAnywhere' '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-oc213> <oid-oc74> NAME 'dmtfPhysicalTape' 'cim22PhysicalTape'
        DESC 'represents 'The PhysicalTape class represents additional data for a
              Tape Media.' Media. Information on the tape length and whether it
              must be unloaded from BOT are properties of this class.'
        SUP dmtfPhysicalMedia
        MUST (tapeLength cim22PhysicalMedia
        MAY (cimTapeLength $ unloadAnywhere) cimUnloadAnywhere)
      )

2.30 dmtfPhysicalLink

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-at534> <oid-at149> NAME 'maxLength' 'cimMaxLength'
        DESC 'The maximum length of the PhysicalLink in feet.'
        SYNTAX binary
        SUP cim22Float64 SINGLE-VALUE
      )

      ( <oid-at535> <oid-at150> NAME 'length' 'cimLength'
        DESC 'The current length of the PhysicalLink in feet.'
        SYNTAX binary feet. For some
              connections, especially wireless technologies, this
              property may not be applicable and should be left
              uninitialized.'

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

        SUP cim22Float64 SINGLE-VALUE
      )

      ( <oid-at536> <oid-at151> NAME 'wired' 'cimWired'
        DESC 'Boolean indicating whether the PhysicalLink is a an actual
              cable (TRUE) or a wireless connection (FALSE).'
        SYNTAX boolean SINGLE-VALUE
      )

      ( <oid-oc214> <oid-oc75> NAME 'dmtfPhysicalLink' 'cim22PhysicalLink'
        DESC 'The PhysicalLink class represents the cabling of
              PhysicalElements together.' 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 dmtfPhysicalElement
        MUST (maxLength cim22PhysicalElement
        MAY (cimMaxLength $ length cimLength $ wired cimWired $ mediaType) cimMediaType)
      )

2.31 dmtfElementsLinkedAuxClass

   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)

      )

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.  In it, antecedentRefs point to dmtfPhysicalLink
   objects and dependentRefs point to dmtfPhysicalElement objects.

      ( <oid-oc215> <oid-oc76> NAME 'dmtfElementsLinkedAuxClass' 'cim22ElementsLinkedAuxClass'
        DESC 'shows 'The ElementsLinked association indicates which
              PhysicalElements are cabled together by a
           PhysicalLink.'
              PhysicalLink. Attribute cimAntecedentRef points to
              cim22PhysicalLink and attribute cimDependentRef points to
              cim22PhysicalElement.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.32 dmtfPhysicalConnector

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.  This class uses two attributes:
   connectorPinout and connectorType.

      ( <oid-at537> <oid-at152> NAME 'connectorPinout' 'cimConnectorPinout'
        DESC 'A free-form string describing the pin configuration and
              signal usage of a PhysicalConnector.'
        SYNTAX string SINGLE-VALUE
      )

      ( <oid-at538> <oid-at153> NAME 'connectorType' 'cimConnectorType'
        DESC 'An array of integers defining the type of
           PhysicalConnector.'
              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-oc216> <oid-oc77> NAME 'dmtfPhysicalConnector' 'cim22PhysicalConnector'
        DESC 'The PhysicalConnector class represents any PhysicalElement
              that is used to connect to other Elements.' 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 dmtfPhysicalElement
        MUST (connectorPinout cim22PhysicalElement
        MAY (cimConnectorPinout $ cimConnectorType)

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 $ connectorType) cim22RealizesAuxClass $
             cim22ProductPhysicalElementsAuxClass $
             cim22FRUPhysicalElementsAuxClass $
             cim22PhysicalElementLocationAuxClass $
             cim22ElementCapacityAuxClass $
             cim22ParticipatesInSetAuxClass $ cim22ContainerAuxClass $
             cim22ElementsLinkedAuxClass $ cim22CollectedMSEsAuxClass $
             cim22ElementConfigurationAuxClass $
             cim22ElementSettingAuxClass $ cim22DependencyAuxClass $
             cim22ProvidesServiceToElementAuxClass $
             cim22ComponentAuxClass $ cim22SystemComponentAuxClass)
      )

2.33 dmtfConnectedToAuxClass

3.33 cim22ConnectedToAuxClass

   This class shows that two or more physical connectors are connected.
   In it, both antecedentRefs and dependentRefs point to
   dmtfPhysicalConnector objects.

      ( <oid-oc217> <oid-oc78> NAME 'dmtfConnectedToAuxClass' 'cim22ConnectedToAuxClass'
        DESC 'shows 'The ConnectedTo association indicates that two or more
              PhysicalConnectors are connected
           together.' together. Both attributes
              point to cim22PhysicalConnector objects.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.34 dmtfSlot

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-at539> <oid-at154> NAME 'supportsHotPlug' 'cimSupportsHotPlug'
        DESC 'Boolean indicating whether the Slot supports hot-plug of
              adapter Cards.'
        SYNTAX boolean SINGLE-VALUE
      )

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

      ( <oid-at540> <oid-at155> NAME 'heightAllowed' 'cimHeightAllowed'
        DESC 'Maximum height of an adapter Card that can be inserted into
              the Slot, in inches.'
        SYNTAX binary inches./
        SUP cim22Float32 SINGLE-VALUE
      )

      ( <oid-at541> <oid-at156> NAME 'lengthAllowed' '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 binary integer SINGLE-VALUE
      )

      ( <oid-at542> <oid-at158> NAME 'vccMixedVoltageSupport' 'cimVccMixedVoltageSupport'
        DESC 'An array of enumerated integers indicating the Vcc voltage
              supported by this Slot.'
        SYNTAX integer
      )

      ( <oid-at543> <oid-at159> NAME 'vppMixedVoltageSupport' 'cimVppMixedVoltageSupport'
        DESC 'An array of enumerated integers indicating the Vpp voltage
              supported by this Slot.'
        SYNTAX integer
      )

      ( <oid-at544> <oid-at160> NAME 'thermalRating' 'cimThermalRating'
        DESC 'Maximum thermal dissipation of the Slot in milliwatts.'
        SYNTAX integer SINGLE-VALUE
      )

      ( <oid-at545> <oid-at161> NAME 'specialPurpose' '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-at546> <oid-at162> NAME 'cimPurposeDescription'
        DESC 'A free-form string describing that this Slot is physically

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 'number' '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-oc218> <oid-oc79> NAME 'dmtfSlot' 'cim22Slot'
        DESC 'The Slot class represents Connectors into which Packages
              are inserted.' 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 dmtfPhysicalConnector
        MUST (connectorType cim22PhysicalConnector
        MAY (cimSupportsHotPlug $ cimHeightAllowed $ supportsHotPlug cimLengthAllowed $ heightAllowed
             cimMaxDataWidth $
           lengthAllowed cimThermalRating $ maxDataWidth
             cimVccMixedVoltageSupport $ vccMixedVoltageSupport cimVppMixedVoltageSupport $
           vppMixedVoltageSupport
             cimSpecialPurpose $ thermalRating 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 $ specialPurpose cim22AdjacentSlotsAuxClass $
           purposeDescription
             cim22PackageInSlotAuxClass $ number) cim22CardInSlotAuxClass)
      )

2.35 dmtfSlotInSlotAuxClass

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.  In this class, antecedentRefs
   point to dmtfSlot objects and dependentRef points to a dmtfSlot
   objects.

      ( <oid-oc219> <oid-oc80> NAME 'dmtfSlotInSlotAuxClass' 'cim22SlotInSlotAuxClass'
        DESC 'represents '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

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.' 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 dmtfConnectedToAuxClass cim22ConnectedToAuxClass AUXILIARY
        MUST (dependentRef)
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.36 dmtfAdjacentSlotsAuxClass

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'.  In it, slotARef and slotBRef both point to
   dmtfCard objects.

      ( <oid-at547> <oid-at164> NAME 'slotARef' 'cimSlotARef'
        DESC 'an 'One of the adjacent Slots.'
        SYNTAX DN SINGLE-VALUE
      )

      ( <oid-at548> <oid-at165> NAME 'slotBRef' 'cimSlotBRef'
        DESC 'The 'other' "other" adjacent Slot.'
        SYNTAX DN SINGLE-VALUE
      )

      ( <oid-at549> <oid-at166> NAME 'distanceBetweenSlots' 'cimDistanceBetweenSlots'
        DESC 'The distance, in inches, between adjacent Slots.'
        SYNTAX binary
        SUP cim22Float32 SINGLE-VALUE
      )

      ( <oid-at550> <oid-at167> NAME 'sharedSlots' 'cimSharedSlots'
        DESC 'Slots can be located near to each other in close proximity on HostingBoards 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 shown indicated by the SharedSlots
              boolean set to TRUE.'

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

        SYNTAX boolean SINGLE-VALUE
      )

      ( <oid-oc220> <oid-oc81> NAME 'dmtfAdjacentSlotsAuxClass' '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' "shared" (if one is
              populated, then the other Slot can not be used), is
              conveyed as properties of the association.' association. Both reference
              attributes point to cim22Slot objects.'
        SUP top AUXILIARY
        MUST (slotARef
        MAY (cimSlotARef $ slotBRef cimSlotBRef $ distanceBetweenSlots cimDistanceBetweenSlots $
           sharedSlots)
             cimSharedSlots)
      )

2.37 dmtfPackageInConnectorAuxClass

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.

   In this class antecedentRefs point to dmtfPhysicalConnector objects
   and dependentRef points to a dmtfPhysicalPackage object.

      ( <oid-oc221> <oid-oc82> NAME 'dmtfPackageInConnectorAuxClass' 'cim22PackageInConnectorAuxClass'
        DESC 'Represents adapter being 'Adapter cards and other "packaging" are plugged into System
              Connectors for power and/or to transfer data.' 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 dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MUST (dependentRef)
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.38 dmtfPackageInSlotAuxClass

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 and in it, antecedentRefs point to
   dmtfSlot objects. capability.

      ( <oid-oc222> <oid-oc83> NAME 'dmtfPackageInSlotAuxClass' '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,

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

              similar to accepting functionality by in the form of adding
              Cards. This
           class association models this capability.' capability.. Attribute
              cimAntecedentRef points to cim22Slot and attribute
              cimDependentRef points to cim22PhysicalPackage.'
        SUP dmtfPackageInConnectorAuxClass cim22PackageInConnectorAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.39 dmtfCardInSlotAuxClass

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, where dependentRef points to a dmtfCard object.
   class.

      ( <oid-oc223> <oid-oc84> NAME 'dmtfCardInSlotAuxClass' '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 here' using the CardInSlot
              association. Attribute cimAntecedentRef points to cim22Slot
              and attribute cimDependentRef points to cim22Card.'
        SUP dmtfPackageInSlotAuxClass cim22PackageInSlotAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.40 dmtfLinkHasConnectorAuxClass

3.40 cim22LinkHasConnectorAuxClass

   Cables and links use physical connectors to connect physical
   elements, which this class explicitly defines.  In it,
   groupComponentRef points to a dmtfPhysicalLink object and
   partComponentRefs point to dmtfPhysicalConnector objects.

      ( <oid-oc224> <oid-oc85> NAME 'dmtfLinkHasConnectorAuxClass' 'cim22LinkHasConnectorAuxClass'
        DESC 'Cables and Links utilize PhysicalConnectors to actually
              "connect" PhysicalElements. This association explicitly
              defines this relationship of Connectors for PhysicalLinks.'
              PhysicalLinks. Attribute cimGroupComponentRef points to
              cim22PhysicalLink and attribute cimPartComponentRef points to
              cim22PhysicalConnector.'
        SUP dmtfComponentAuxClass cim22ComponentAuxClass AUXILIARY
        MAY (cimGroupComponentRef $ cimPartComponentRef)
      )

2.41 dmtfConnectorOnPackageAuxClass

3.41 cim22ConnectorOnPackageAuxClass

   Physical packages contain connectors and other physical elements,
   which this class makes explicit.  In it, groupComponentRef points to
   a dmtfPhysicalPackage object and partComponentRefs point to
   dmtfPhysicalConnector objects.

      ( <oid-oc225> <oid-oc86> NAME 'dmtfConnectorOnPackageAuxClass' 'cim22ConnectorOnPackageAuxClass'
        DESC 'PhysicalPackages contain Connectors as well as other
              PhysicalElements. This class The ConnectorOnPackage association makes

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

              explicit the containment relationship between Connectors
              and Packages.' Packages. Attribute cimGroupComponentRef points to
              cim22PhysicalPackage and attribute cimPartComponentRef points
              to cim22PhysicalConnector.'
        SUP dmtfContainerAuxClass cim22ContainerAuxClass AUXILIARY
        MAY (cimGroupComponentRef $ cimPartComponentRef $
             cimLocationWithinContainer)
      )

2.42 dmtfAdapterActiveConnectionAuxClass

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.  In this class,
   antecedentRefs point to dmtfPhysicalConnector objects and
   dependentRefs point to dmtfNetworkAdapter objects.

      ( <oid-oc226> <oid-oc87> NAME 'dmtfAdapterActiveConnectionAuxClass' 'cim22AdapterActiveConnectionAuxClass'
        DESC 'shows 'The AdapterActiveConnection relationship indicates that a
              NetworkAdapter is using the referenced PhysicalConnector to
              output to the network.' 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 dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.43 dmtfComputerSystemPackageAuxClass

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.  In it, antecedentRefs point to
   dmtfPhysicalPackage objects and dependentRefs point to
   dmtfUnitaryComputerSystem objects.

      ( <oid-at551> <oid-at168> NAME 'platformGUID' 'cimPlatformGUID'
        DESC 'A Gloabally Unique Identifier for the System's Package.'
        SYNTAX string SINGLE-VALUE
      )

      ( <oid-oc227> <oid-oc88> NAME 'dmtfComputerSystemPackageAuxClass' '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.' relationship. Attribute
              cimAntecedentRef points to cim22PhysicalPackage and attribute

INTERNET DRAFTLDAP Schema for the DMTF Physical CIM v2.2 ModelDecember
1999

              cimDependentRef points to cim22UnitaryComputerSystem.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MUST (platformGUID)
        MAY (cimAntecedentRef $ cimDependentRef $ cimPlatformGUID)
      )

2.44 dmtfLibraryPackageAuxClass

3.44 cim22LibraryPackageAuxClass

   Similar to the way that physical element 'realize' logical devices,
   physical packages 'realize' storage libraries.  This class explicitly
   defines this relationship, in which antecedentRefs point to
   dmtfPhysicalPackage objects and dependentRefs point to
   dmtfStorageLibrary objects. relationship.

      ( <oid-oc228> <oid-oc89> NAME 'dmtfLibraryPackageAuxClass' 'cim22LibraryPackageAuxClass'
        DESC 'Similar to the way that LogicalDevices are "Realized" by
              PhysicalElements, a StorageLibrary can be realized in one
              or more PhysicalPackages. This class The LibraryPackage association
              explicitly defines this relationship.' relationship. Attribute
              cimAntecedentRef points to cim22PhysicalPackage and attribute
              cimDependentRef points to cim22StorageLibrary.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.45 dmtfPackageCoolingAuxClass

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, in which antecedentRefs point to dmtfCoolingDevice objects and
   dependentRefs point to dmtfPhysicalPackage objects.
   class.

      ( <oid-oc229> <oid-oc90> NAME 'dmtfPackageCoolingAuxClass' '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 this class.' the PackageCooling association. Attribute
              cimAntecedentRef points to cim22CoolingDevice. Attribute
              cimDependentRef points to cim22PhysicalPackage.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
        MAY (cimAntecedentRef $ cimDependentRef)
      )

2.46 dmtfPackageAlarmAuxClass

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, where
   antecedentRefs point to dmtfAlarmDevice objects and dependentRefs
   point to dmtfPhysicalPackage objects. class.

      ( <oid-oc230> <oid-oc91> NAME 'dmtfPackageAlarmAuxClass' 'cim22PackageAlarmAuxClass'
        DESC 'Often, an AlarmDevice is installed as part of a Package,
              not to show indicate issues with any particular LogicalDevice or

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 this class.' the PackageAlarm
              association. Attribute cimAntecedentRef points to
              cim22AlarmDevice and attribute cimDependentRef points to
              cim22PhysicalPackage.'
        SUP dmtfDependencyAuxClass cim22DependencyAuxClass AUXILIARY
      )

3. DIT Content Rules

   The following DIT Content Rules apply to objects in this schema.
   These content rules reference not only classes in this
   draft but classes from other DMTF CIM models [5, 6, 7, 8, 9]

      ( <oid-oc185> NAME 'dmtfLocationContentRule'
        DESC 'shows what auxiliary classes may go with the dmtfLocation
           class'
        AUX (dmtfPhysicalElementLocationAuxClass)
      )
      ( <oid-oc187> NAME 'dmtfPhysicalCapacityContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalCapacity class'
        AUX (dmtfElementCapacityAuxClass)
      )

      ( <oid-oc191> NAME 'dmtfReplacementSetContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfReplacementSet class'
        AUX (dmtfParticipatesInSetAuxClass)
      )

      ( <oid-oc193> NAME 'dmtfPhysicalPackageContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalPackage class'
        AUX (dmtfContainerAuxClass $ dmtfPackageInChassisAuxClass $
          dmtfPackagedComponentAuxClass $
          dmtfPackageInConnectorAuxClass $ dmtfPackageInSlotAuxClass $
          dmtfConnectorOnPackageAuxClass $
          dmtfComputerSystemPackageAuxClass $
          dmtfLibraryPackageAuxClass $ dmtfPackageCoolingAuxClass $
          dmtfPackageAlarmAuxClass)
      )

      ( <oid-oc196> NAME 'dmtfRackContentRule'
        DESC 'shows what auxiliary classes may go with the dmtfRack
           class'
        AUX (dmtfChassisInRackAuxClass)
      )

      ( <oid-oc197> NAME 'dmtfChassisContentRule'
        DESC 'shows what auxiliary classes may go with the dmtfChassis
           class'
        AUX (dmtfChassisInRackAuxClass $ dmtfPackageInChassisAuxClass $
          dmtfDockedAuxClass)
      )

      ( <oid-oc201> NAME 'dmtfCardContentRule'
        DESC 'shows what auxiliary classes may go with the dmtfCard
           class'
        AUX (dmtfCardOnCardAuxClass $ dmtfMemoryOnCardAuxClass $
          dmtfCardInSlotAuxClass)
      )

      ( <oid-oc204> NAME 'dmtfStorageMediaLocationContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfStorageMediaLocation class'
        AUX (dmtfPhysicalMediaInLocationAuxClass)

      )

      ( <oid-oc205> NAME 'dmtfPhysicalComponentContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalComponent class'
        AUX (dmtfPackagedComponentAuxClass)
      )

      ( <oid-oc208> NAME 'dmtfPhysicalMemoryContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalMemory class'
        AUX (dmtfMemoryOnCardAuxClass $ dmtfMemoryWithMediaAuxClass)
      )

      ( <oid-oc210> NAME 'dmtfPhysicalMediaContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalMedia class'
        AUX (dmtfMemoryWithMediaAuxClass $
          dmtfPhysicalMediaInLocationAuxClass)
      )

      ( <oid-oc214> NAME 'dmtfPhysicalLinkContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalLink class'
        AUX (dmtfElementsLinkedAuxClass $ dmtfLinkHasConnectorAuxClass)
      )

      ( <oid-oc216> NAME 'dmtfPhysicalConnectorContentRule'
        DESC 'shows what auxiliary classes may go with the
           dmtfPhysicalConnector class'
        AUX (dmtfConnectedToAuxClass $ dmtfConnectedToAuxClass $
          dmtfPackageInConnectorAuxClass $
          dmtfLinkHasConnectorAuxClass $
          dmtfConnectorOnPackageAuxClass $
          dmtfAdapterActiveConnectionAuxClass $
          dmtfAdapterActiveConnectionAuxClass)
      )

      ( <oid-oc218> NAME 'dmtfSlotContentRule'
        DESC 'shows what auxiliary classes may go with the dmtfSlot
           class'
        AUX (dmtfSlotInSlotAuxClass $ dmtfAdjacentSlotsAuxClass
        MAY (cimAntecedentRef $
          dmtfPackageInSlotAuxClass $ dmtfCardInSlotAuxClass) 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, "Lightweight "Light-
                     weight Directory Access Protocol (v3): Attribute
                     Syntax Defini-
            tions," 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", September Internet
                     Draft (work in progress), December 1999.

         [6]         Ryan Moats, Gerald Maziarski, John Strassner, "LDAP Schema
            for the DMTF Device CIM Model", September 1999.

[7]         Ryan Moats, Gerald Maziarski, John Strassner, "LDAP Schema
            for the DMTF Network CIM Model", October 1999.

[8]         Ryan Moats, Gerald Maziarski, John Strassner, "LDAP Schema
            for the DMTF System CIM Model", October 1999.

[9]         Ryan Moats, Gerald Maziarski, John Strassner, "LDAP Schema         Doug Wood, "Directory string representation for the DMTF Application CIM Model", October
                     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