Internet-Draft Ryan Moats draft-moats-dmtf-physical-ldap-00.txt Gerald Maziarski Expires in six months AT&T John Strassner cisco Systems October 1999 LDAP Schema for the DMTF Physical CIM Model Filename: draft-moats-dmtf-physical-ldap-00.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. 2. 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 Expires 4/30/00 [Page 1]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 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 OIDs are place holders, and 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 no TemperatureSensors in the schema. 2.1 dmtfLocation Locations are the position and address of a PhysicalElement. This class reuses the name attribute and defines the attributes physicalPosition and address. ( <oid-at462> NAME 'physicalPosition' 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.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at463> NAME 'address' 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> NAME 'dmtfLocation' DESC 'specifies the position and address of a PhysicalElement.' SUP top MUST (name $ physicalPosition $ address) Expires 4/30/00 [Page 2]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ) 2.2 dmtfPhysicalElementLocationAuxClass This class associates a physical element with a dmtfLocation 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> NAME 'dmtfLocationRef' DESC 'The Physical Element's Location. May be used as an RDN.' SYNTAX DN SINGLE-VALUE ) ( <oid-oc186> NAME 'dmtfPhysicalElementLocationAuxClass' DESC 'associates a PhysicalElement with a Location object for inventory or replacement purposes.' SUP top AUXILIARY MUST (dmtfPhysicalElementRefs $ dmtfLocationRef) ) 2.3 dmtfPhysicalCapacity This class describes a physical element's requirements. It reuses the attributes name, caption, and description. ( <oid-oc187> NAME 'dmtfPhysicalCapacity' DESC 'abstract class describing a PhysicalElement's minimum/maximum requirements and ability to support different types of hardware.' SUP top ABSTRACT MUST (name $ caption $ description) ) 2.4 dmtfElementCapacityAuxClass This class associates a dmtfPhysicalCapacity object with one or more dmtfPhysicalElements. It defines the attributes dmtfPhysicalCapacityRefs and dmtfPhysicalElementRefs. ( <oid-at466> NAME 'dmtfPhysicalCapacityRefs' DESC 'PhysicalCapacity describes the minimum and maximum requirements, and ability to support different types of Expires 4/30/00 [Page 3]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 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.' SYNTAX DN ) ( <oid-oc188> NAME 'dmtfElementCapacityAuxClass' DESC 'associates a PhysicalCapacity object with one or more PhysicalElements.' SUP top AUXILIARY MUST (dmtfPhysicalCapacityRefs $ dmtfPhysicalElementRefs) ) 2.5 dmtfMemoryCapacity 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> NAME 'memoryType' 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".' SYNTAX integer SINGLE-VALUE ) ( <oid-at469> NAME 'minimumMemoryCapacity' DESC 'Minimum amount of memory, in Kbytes, that is needed for the associated PhysicalElement to operate correctly.' SYNTAX integer SINGLE-VALUE ) ( <oid-at470> NAME 'maximumMemoryCapacity' DESC 'Maximum amount of memory, in Kbytes, that can be supported by the associated PhysicalElement.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc189> NAME 'dmtfMemoryCapacity' Expires 4/30/00 [Page 4]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 DESC 'describes the type of Memory that can be installed on a PhysicalElement and its minimum/maximum configurations.' SUP dmtfPhysicalCapacity MUST (memoryType $ minimumMemoryCapacity $ maximumMemoryCapacity) ) 2.6 dmtfConfigurationCapacity 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 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> NAME 'objectType' DESC 'The type of object (power supply, fan, disk drive, ..) whose capacities are shown. May be used as an RDN.' SYNTAX integer SINGLE-VALUE ) ( <oid-at472> NAME 'minimumCapacity' DESC 'Minimum number of Elements of type, ObjectType, that must be installed.' SYNTAX integer SINGLE-VALUE ) ( <oid-at473> NAME 'maximumCapacity' DESC 'Maximum number of Elements of type, ObjectType, that may be installed.' SYNTAX integer SINGLE-VALUE ) ( <oid-at474> NAME 'increment' DESC 'Increment in which Elements must be added or removed.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc190> NAME 'dmtfConfigurationCapacity' DESC 'ConfigurationCapacity provides information on the minimum Expires 4/30/00 [Page 5]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 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).' SUP dmtfPhysicalCapacity MUST (objectType $ otherTypeDescription $ minimumCapacity $ maximumCapacity $ increment) ) 2.7 dmtfReplacementSet 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> NAME 'dmtfReplacementSet' DESC 'The ReplacementSet class aggregates PhysicalElements that must be "replaced" or "FRUed" together.' SUP top MUST (name $ description) ) 2.8 dmtfParticipatesInSetAuxClass This class shows which physical elements should be replaced together. It defines the attributes dmtfReplacementSetRefs and dmtfPhysicalElementRefs. ( <oid-at475> NAME 'dmtfReplacementSetRefs' DESC 'The ReplacementSet.' SYNTAX DN ) ( <oid-at476> NAME 'dmtfPhysicalElementRefs' DESC 'The PhysicalElement that should be replaced with other Elements, as a Set.' SYNTAX DN ) ( <oid-oc192> NAME 'dmtfParticipatesInSetAuxClass' DESC 'shows which PhysicalElements should be replaced together.' SUP top AUXILIARY MUST (dmtfReplacementSetRefs $ dmtfPhysicalElementRefs) ) Expires 4/30/00 [Page 6]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 2.9 dmtfPhysicalPackage A physical package contains or hosts components. Examples are a rack enclosure or an adapter Card. ( <oid-at477> NAME 'removable' DESC 'An object 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 can still be Removable if power must be "off" to perform the removal. If power can be "on" and the Component removed, then the Element is both Removable and HotSwappable. For example, an upgradeable Processor chip is Removable.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at478> NAME 'replaceable' DESC 'An object 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, the Processor is said to be Replaceable. All Removable Components are inherently Replaceable.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at479> NAME 'hotSwappable' DESC 'An object is HotSwappable if it is possible to replace the Element with a physically different but equivalent one while the containing Package is "on". For example, a fan Component may be designed to be HotSwappable. All HotSwappable Components are inherently Removable and Replaceable.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at480> NAME 'height' DESC 'The height of the object.' SYNTAX binary SINGLE-VALUE ) ( <oid-at481> NAME 'depth' DESC 'The depth of the object.' SYNTAX binary SINGLE-VALUE ) ( <oid-at482> NAME 'width' Expires 4/30/00 [Page 7]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 DESC 'The width of the object.' SYNTAX binary SINGLE-VALUE ) ( <oid-at483> NAME 'weight' DESC 'The weight of the object.' SYNTAX binary SINGLE-VALUE ) ( <oid-oc193> NAME 'dmtfPhysicalPackage' DESC 'The PhysicalPackage class represents PhysicalElements that contain or host other components.' SUP dmtfPhysicalElement MUST (removable $ replaceable $ hotSwappable $ height $ depth $ width $ weight) ) 2.10 dmtfContainerAuxClass 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> NAME 'locationWithinContainer' 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 object.' SYNTAX string SINGLE-VALUE ) ( <oid-oc194> NAME 'dmtfContainerAuxClass' DESC 'The Container association represents the relationship between a contained and a containing PhysicalElement.' SUP dmtfComponentAuxClass AUXILIARY MUST (groupComponentRef $ locationWithinContainer) ) Expires 4/30/00 [Page 8]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 2.11 dmtfPhysicalFrame A physical frame is a generic frame enclosure. ( <oid-at486> NAME 'cableManagementStrategy' 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, storage-related and power cables, cable management can be a complex and challenging task. This string property contains information to aid in assembly and service of the Frame.' SYNTAX string SINGLE-VALUE ) ( <oid-at487> NAME 'servicePhilosophy' 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 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".' SYNTAX integer ) ( <oid-at488> NAME 'serviceDescriptions' DESC 'An array of free-form strings providing more detailed explanations for any of the entries in the ServicePhilosophy array.' SYNTAX string ) ( <oid-at489> NAME 'lockPresent' DESC 'Boolean indicating whether the Frame is protected with a lock.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at490> NAME 'securityBreach' 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" or "No Breach".' SYNTAX integer SINGLE-VALUE ) Expires 4/30/00 [Page 9]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ( <oid-at491> NAME 'breachDescription' DESC 'BreachDescription is a free-form string providing more information if the SecurityBreach property shows that a breach or some other security-related event occurred.' SYNTAX string SINGLE-VALUE ) ( <oid-oc195> NAME 'dmtfPhysicalFrame' DESC 'PhysicalFrame is a superclass of Rack, Chassis and other frame enclosures, as they are defined in extension classes.' SUP dmtfPhysicalPackage MUST (cableManagementStrategy $ servicePhilosophy $ serviceDescriptions $ lockPresent $ audibleAlarm $ visibleAlarm $ securityBreach $ breachDescription $ isLocked) ) 2.12 dmtfRack 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> NAME 'typeOfRack' DESC 'Enumeration indicating the type of Rack. Specifies information such as "Telco" or 19 inch rack (1). Allowed values are: "Unknown", "Standard 19 Inch", "Telco", "Equipment Shelf", "Non-Standard".' SYNTAX integer SINGLE-VALUE ) ( <oid-at493> NAME 'countryDesignation' DESC 'Country for which the Rack is designed. ISO/IEC 3166 defines country code strings.' SYNTAX string SINGLE-VALUE ) ( <oid-oc196> NAME 'dmtfRack' DESC 'A Rack is a PhysicalFrame that represents an enclosure in which Chassis are placed.' SUP dmtfPhysicalFrame MUST (height $ typeOfRack $ countryDesignation) ) Expires 4/30/00 [Page 10]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 2.13 dmtfChassis Chassis enclose other elements and provide definable functionality. ( <oid-at494> NAME 'numberOfPowerCords' DESC 'Integer indicating the number of power cords that must be connected to the Chassis, for all the componentry to operate.' SYNTAX integer SINGLE-VALUE ) ( <oid-at495> NAME 'currentRequiredOrProduced' DESC 'Current required by the Chassis at 120V. If power is provided by the Chassis (as for a UPS), this property may be the amperage produced, as a negative number.' SYNTAX binary SINGLE-VALUE ) ( <oid-at496> NAME 'heatGeneration' 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> NAME 'dmtfChassis' 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 $ currentRequiredOrProduced $ heatGeneration $ chassisTypes $ typeDescriptions) ) Expires 4/30/00 [Page 11]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 2.14 dmtfChassisInRackAuxClass 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> NAME 'bottomU' DESC 'An integer indicating the lowest or 'bottom' U in which the Chassis is mounted. A 'U' is a standard unit of measure for the height of a Rack or rack-mountable component. It is equal to 1.75 inches or 4.445 cm.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc198> NAME 'dmtfChassisInRackAuxClass' DESC 'makes explicit the "containing" relationship between the Rack and the Chassis.' SUP dmtfContainerAuxClass AUXILIARY MUST (bottomU) ) 2.15 dmtfPackageInChassisAuxClass 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> NAME 'dmtfPackageInChassisAuxClass' DESC 'A Chassis can contain other Packages, such as other Chassis and Cards. The PackageInChassis association makes explicit this relationship.' SUP dmtfContainerAuxClass AUXILIARY ) 2.16 dmtfDockedAuxClass 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> NAME 'antecedentRef' DESC 'A single object that is dependend on.' SYNTAX DN SINGLE-VALUE ) Expires 4/30/00 [Page 12]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ( <oid-at501> NAME 'dependentRef' DESC 'A single dependent object.' SYNTAX DN SINGLE-VALUE ) ( <oid-oc200> NAME 'dmtfDockedAuxClass' DESC 'A laptop, a type of Chassis, may be docked in another type of Chassis, a Docking Station.' SUP dmtfDependencyAuxClass AUXILIARY MUST (antecedentRef $ dependentRef) ) 2.17 dmtfCard 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> NAME 'hostingBoard' DESC 'Boolean indicating that this Card is a Motherboard or, more generically, a baseboard in a Chassis.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at503> NAME 'slotLayout' 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> NAME 'requiresDaughterBoard' DESC 'Boolean indicating that at least one daughterboard or auxiliary Card is required to function properly.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at505> NAME 'specialRequirements' DESC 'Boolean indicating that this Card is physically unique from other Cards of the same type and therefore requires a special Slot.' SYNTAX boolean SINGLE-VALUE Expires 4/30/00 [Page 13]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ) ( <oid-at506> NAME 'requirementsDescription' 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> NAME 'operatingVoltages' DESC 'Operating voltages required by the Card.' SYNTAX binary ) ( <oid-oc201> NAME 'dmtfCard' 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.' SUP dmtfPhysicalPackage MUST (hostingBoard $ slotLayout $ requiresDaughterBoard $ specialRequirements $ requirementsDescription $ operatingVoltages) ) 2.18 dmtfSystemBusCard 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> NAME 'busType' DESC 'An enumerated integer describing the System bus type for this Card. It shows 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.' SYNTAX integer SINGLE-VALUE ) ( <oid-at509> NAME 'busWidth' 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> NAME 'dmtfSystemBusCard' Expires 4/30/00 [Page 14]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 DESC 'The SystemBusCard class represents additional information for a Card, detailing the Card's bus type and data width.' SUP dmtfCard MUST (busType $ busWidth) ) 2.19 dmtfCardOnCardAuxClass 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. ( <oid-at510> NAME 'mountOrSlotDescription' DESC 'A string describing and identifying how the Card is mounted on or plugged into the "other" Card. This attribute could store slot information, which may be enough 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 information is available, this field could be used to provide more detailed mounting or slot insertion data.' SYNTAX string SINGLE-VALUE ) ( <oid-oc203> NAME 'dmtfCardOnCardAuxClass' DESC 'Cards may be plugged into Motherboards/baseboards, are daughtercards of an adapter, or support special Card-like modules.' SUP dmtfContainerAuxClass AUXILIARY MUST (mountOrSlotDescription) ) 2.20 dmtfStorageMediaLocation A storage media location holds media and goes beyond being just a location used by a storage library. ( <oid-at511> NAME 'locationType' DESC 'The type of Location. For example, whether this is an individual Media "Slot" or a "Magazine"property. Allowed values are: "Unknown", "Other", "Slot", "Magazine", "MediaAccessDevice", "InterLibrary Port", "Limited Access Port", "Door", "Shelf", "Vault".' SYNTAX integer SINGLE-VALUE Expires 4/30/00 [Page 15]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ) ( <oid-at512> NAME 'locationCoordinates' 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> NAME 'mediaCapacity' DESC 'A StorageMediaLocation may hold more than one PhysicalMedia - for example, a Magazine. This property shows the PhysicalMedia capacity of the Location.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc204> NAME 'dmtfStorageMediaLocation' DESC 'a PhysicalElement where PhysicalMedia may be placed.' SUP dmtfPhysicalPackage MUST (locationType $ locationCoordinates $ mediaTypesSupported $ mediaSizesSupported $ mediaCapacity) ) 2.21 dmtfPhysicalComponent 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> NAME 'dmtfPhysicalComponent' DESC 'represents any low-level or basic Component within a Package.' SUP dmtfPhysicalElement Expires 4/30/00 [Page 16]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 MUST (removable $ replaceable $ hotSwappable) ) 2.22 dmtfPackagedComponentAuxClass 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> NAME 'dmtfPackagedComponentAuxClass' DESC 'A Component is typically contained by a PhysicalPackage, such as a Chassis or Card.' SUP dmtfContainerAuxClass AUXILIARY ) 2.23 dmtfChip A chip is of IC hardware, including ASICs, processors, and memory chips. ( <oid-at516> NAME 'formFactor' DESC 'The implementation form factor for the 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".' SYNTAX integer SINGLE-VALUE ) ( <oid-oc207> NAME 'dmtfChip' DESC 'represents any type of integrated circuit hardware, including ASICs, processors, memory chips, etc.' SUP dmtfPhysicalComponent MUST (formFactor) ) 2.24 dmtfPhysicalMemory Physical memory are low level memory devices. ( <oid-at517> NAME 'totalWidth' DESC 'Total width, in bits, of the PhysicalMemory, including check or error correction bits. If there are no error Expires 4/30/00 [Page 17]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 correction bits, the value in this property should match that specified for DataWidth.' SYNTAX integer SINGLE-VALUE ) ( <oid-at518> NAME 'capacity' DESC 'The total capacity of this PhysicalMemory, in bytes.' SYNTAX integer SINGLE-VALUE ) ( <oid-at519> NAME 'bankLabel' DESC 'A string identifying the physically labeled bank where the Memory is located' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at520> NAME 'positionInRow' DESC 'Specifies the position of the PhysicalMemory in a "row". For example, if it takes two 8-bit memory devices to form a 16-bit row, then a value of "2" means that this Memory is the second device.' SYNTAX integer SINGLE-VALUE ) ( <oid-at521> NAME 'interleavePosition' DESC 'The position of this PhysicalMemory in an interleave. 0 for non-interleaved. 1 for the first position, 2 for the second position and so on.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc208> NAME 'dmtfPhysicalMemory' DESC 'subclass representing low level memory devices - SIMMS, DIMMs, raw memory chips, etc.' SUP dmtfChip MUST (formFactor $ memoryType $ totalWidth $ dataWidth $ speed $ capacity $ bankLabel $ positionInRow $ interleavePosition) ) 2.25 dmtfMemoryOnCardAuxClass 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. ( <oid-oc209> NAME 'dmtfMemoryOnCardAuxClass' DESC 'Explicitly defines the relationship of cards containing Expires 4/30/00 [Page 18]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 memory.' SUP dmtfPackagedComponentAuxClass AUXILIARY ) 2.26 dmtfPhysicalMedia 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> NAME 'mediaType' DESC 'Specifies the type of the PhysicalMedia, as an enumerated integer.' SYNTAX integer SINGLE-VALUE ) ( <oid-at523> NAME 'mediaDescription' DESC 'Additional detail related to the MediaType enumeration.' SYNTAX string SINGLE-VALUE ) ( <oid-at524> NAME 'writeProtectOn' DESC 'Boolean specifying whether the Media is currently write protected by some physical mechanism, such as a protect tab on a floppy diskette.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at525> NAME 'cleanerMedia' DESC 'Boolean indicating that the PhysicalMedia is used for cleaning purposes and not data storage.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at526> NAME 'mediaSize' DESC 'Size of the Media in inches.' SYNTAX binary SINGLE-VALUE ) ( <oid-at527> NAME 'maxMounts' 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 Expires 4/30/00 [Page 19]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ) ( <oid-at528> NAME 'dualSided' 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> NAME 'labelFormats' 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 any type of documentation or storage medium, such as tapes, CDROMs, etc.' SUP dmtfPhysicalComponent MUST (capacity $ mediaType $ mediaDescription $ writeProtectOn $ cleanerMedia $ mediaSize $ maxMounts $ dualSided $ physicalLabels $ labelStates $ labelFormats) ) 2.27 dmtfMemoryWithMediaAuxClass 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. Expires 4/30/00 [Page 20]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ( <oid-oc211> NAME 'dmtfMemoryWithMediaAuxClass' DESC 'shows that Memory is associated with a PhysicalMedia and its cartridge.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.28 dmtfPhysicalMediaInLocationAuxClass Within a storage library, all media should be accounted for, and be present in some storage location. In addition, one can determine if a location is empty or full based on whether this `auxiliary class is attached to a dmtfStorageMediaLocation object. In this class, antecedentRef points to a single dmtfStorageMediaLocation object and dependentRefs point to dmtfPhysicalMedia objects. ( <oid-oc212> NAME 'dmtfPhysicalMediaInLocationAuxClass' DESC 'Within a StorageLibrary, all Media should be accounted for, and be present in some Storage Location. This relationship is made explicit here' SUP dmtfDependencyAuxClass AUXILIARY MUST (antecedentRef) ) 2.29 dmtfPhysicalTape This class represents data for a tape Media, including information on the length and whether it must be unloaded from BOT. ( <oid-at532> NAME 'tapeLength' DESC 'The physical length of the Tape in feet.' SYNTAX binary SINGLE-VALUE ) ( <oid-at533> NAME 'unloadAnywhere' 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> NAME 'dmtfPhysicalTape' DESC 'represents additional data for a Tape Media.' SUP dmtfPhysicalMedia MUST (tapeLength $ unloadAnywhere) ) Expires 4/30/00 [Page 21]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 2.30 dmtfPhysicalLink 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> NAME 'maxLength' DESC 'The maximum length of the PhysicalLink in feet.' SYNTAX binary SINGLE-VALUE ) ( <oid-at535> NAME 'length' DESC 'The current length of the PhysicalLink in feet.' SYNTAX binary SINGLE-VALUE ) ( <oid-at536> NAME 'wired' DESC 'Boolean indicating whether the PhysicalLink is a cable (TRUE) or a wireless connection (FALSE).' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc214> NAME 'dmtfPhysicalLink' DESC 'The PhysicalLink class represents the cabling of PhysicalElements together.' SUP dmtfPhysicalElement MUST (maxLength $ length $ wired $ mediaType) ) 2.31 dmtfElementsLinkedAuxClass 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> NAME 'dmtfElementsLinkedAuxClass' DESC 'shows which PhysicalElements are cabled together by a PhysicalLink.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.32 dmtfPhysicalConnector 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 Expires 4/30/00 [Page 22]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 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> NAME 'connectorPinout' DESC 'A free-form string describing the pin configuration and signal usage of a PhysicalConnector.' SYNTAX string SINGLE-VALUE ) ( <oid-at538> NAME 'connectorType' DESC 'An array of integers defining the type of PhysicalConnector.' SYNTAX integer ) ( <oid-oc216> NAME 'dmtfPhysicalConnector' DESC 'The PhysicalConnector class represents any PhysicalElement that is used to connect to other Elements.' SUP dmtfPhysicalElement MUST (connectorPinout $ connectorType) ) 2.33 dmtfConnectedToAuxClass This class shows that two or more physical connectors are connected. In it, both antecedentRefs and dependentRefs point to dmtfPhysicalConnector objects. ( <oid-oc217> NAME 'dmtfConnectedToAuxClass' DESC 'shows that two or more PhysicalConnectors are connected together.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.34 dmtfSlot 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> NAME 'supportsHotPlug' DESC 'Boolean indicating whether the Slot supports hot-plug of adapter Cards.' SYNTAX boolean SINGLE-VALUE ) Expires 4/30/00 [Page 23]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ( <oid-at540> NAME 'heightAllowed' DESC 'Maximum height of an adapter Card that can be inserted into the Slot, in inches.' SYNTAX binary SINGLE-VALUE ) ( <oid-at541> NAME 'lengthAllowed' DESC 'Maximum length of an adapter Card that can be inserted into the Slot, in inches.' SYNTAX binary SINGLE-VALUE ) ( <oid-at542> NAME 'vccMixedVoltageSupport' DESC 'An array of enumerated integers indicating the Vcc voltage supported by this Slot.' SYNTAX integer ) ( <oid-at543> NAME 'vppMixedVoltageSupport' DESC 'An array of enumerated integers indicating the Vpp voltage supported by this Slot.' SYNTAX integer ) ( <oid-at544> NAME 'thermalRating' DESC 'Maximum thermal dissipation of the Slot in milliwatts.' SYNTAX integer SINGLE-VALUE ) ( <oid-at545> NAME 'specialPurpose' 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> NAME 'number' DESC 'The Number property indicates the physical slot number, which can be used as an index into a system slot table, whether that slot is physically occupied.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc218> NAME 'dmtfSlot' DESC 'The Slot class represents Connectors into which Packages are inserted.' Expires 4/30/00 [Page 24]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 SUP dmtfPhysicalConnector MUST (connectorType $ supportsHotPlug $ heightAllowed $ lengthAllowed $ maxDataWidth $ vccMixedVoltageSupport $ vppMixedVoltageSupport $ thermalRating $ specialPurpose $ purposeDescription $ number) ) 2.35 dmtfSlotInSlotAuxClass 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> NAME 'dmtfSlotInSlotAuxClass' DESC 'represents the ability of a special adapter to extend the existing Slot structure to enable otherwise incompatible Cards to be plugged into a Frame or HostingBoard.' SUP dmtfConnectedToAuxClass AUXILIARY MUST (dependentRef) ) 2.36 dmtfAdjacentSlotsAuxClass 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> NAME 'slotARef' DESC 'an adjacent Slots.' SYNTAX DN SINGLE-VALUE ) ( <oid-at548> NAME 'slotBRef' DESC 'The 'other' adjacent Slot.' SYNTAX DN SINGLE-VALUE ) ( <oid-at549> NAME 'distanceBetweenSlots' DESC 'The distance, in inches, between adjacent Slots.' SYNTAX binary SINGLE-VALUE ) ( <oid-at550> NAME 'sharedSlots' DESC 'Slots can be located near to each other on HostingBoards or Expires 4/30/00 [Page 25]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 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 by the SharedSlots boolean set to TRUE.' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc220> NAME 'dmtfAdjacentSlotsAuxClass' DESC 'AdjacentSlots describes the layout of Slots on a HostingBoard or adapter Card. Information like the distance between the Slots and whether they are 'shared' (if one is populated, then the other Slot can not be used), is conveyed as properties of the association.' SUP top AUXILIARY MUST (slotARef $ slotBRef $ distanceBetweenSlots $ sharedSlots) ) 2.37 dmtfPackageInConnectorAuxClass 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> NAME 'dmtfPackageInConnectorAuxClass' DESC 'Represents adapter being plugged into System Connectors for power and/or to transfer data.' SUP dmtfDependencyAuxClass AUXILIARY MUST (dependentRef) ) 2.38 dmtfPackageInSlotAuxClass 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. ( <oid-oc222> NAME 'dmtfPackageInSlotAuxClass' 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, similar to accepting functionality by adding Cards. This Expires 4/30/00 [Page 26]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 class models this capability.' SUP dmtfPackageInConnectorAuxClass AUXILIARY ) 2.39 dmtfCardInSlotAuxClass 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. ( <oid-oc223> NAME 'dmtfCardInSlotAuxClass' 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' SUP dmtfPackageInSlotAuxClass AUXILIARY ) 2.40 dmtfLinkHasConnectorAuxClass 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> NAME 'dmtfLinkHasConnectorAuxClass' DESC 'Cables and Links utilize PhysicalConnectors to actually "connect" PhysicalElements. This association explicitly defines this relationship of Connectors for PhysicalLinks.' SUP dmtfComponentAuxClass AUXILIARY ) 2.41 dmtfConnectorOnPackageAuxClass 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> NAME 'dmtfConnectorOnPackageAuxClass' DESC 'PhysicalPackages contain Connectors as well as other PhysicalElements. This class makes explicit the containment relationship between Connectors and Packages.' SUP dmtfContainerAuxClass AUXILIARY ) Expires 4/30/00 [Page 27]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 2.42 dmtfAdapterActiveConnectionAuxClass 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> NAME 'dmtfAdapterActiveConnectionAuxClass' DESC 'shows that a NetworkAdapter is using the referenced PhysicalConnector to output to the network.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.43 dmtfComputerSystemPackageAuxClass 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> NAME 'platformGUID' DESC 'A Gloabally Unique Identifier for the System's Package.' SYNTAX string SINGLE-VALUE ) ( <oid-oc227> NAME 'dmtfComputerSystemPackageAuxClass' 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.' SUP dmtfDependencyAuxClass AUXILIARY MUST (platformGUID) ) 2.44 dmtfLibraryPackageAuxClass 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. ( <oid-oc228> NAME 'dmtfLibraryPackageAuxClass' DESC 'Similar to the way that LogicalDevices are "Realized" by PhysicalElements, a StorageLibrary can be realized in one or more PhysicalPackages. This class explicitly defines Expires 4/30/00 [Page 28]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 this relationship.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.45 dmtfPackageCoolingAuxClass 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. ( <oid-oc229> NAME 'dmtfPackageCoolingAuxClass' 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.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.46 dmtfPackageAlarmAuxClass 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. ( <oid-oc230> NAME 'dmtfPackageAlarmAuxClass' DESC 'Often, an AlarmDevice is installed as part of a Package, not to show issues with any particular LogicalDevice or PhysicalComponent, but with the Package's environment in general, its security state or its overall health. This relationship is described by this class.' SUP dmtfDependencyAuxClass 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) ) Expires 4/30/00 [Page 29]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ( <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) Expires 4/30/00 [Page 30]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 ) ( <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 $ dmtfPackageInSlotAuxClass $ dmtfCardInSlotAuxClass) ) Expires 4/30/00 [Page 31]
INTERNET DRAFT LDAP Schema for the DMTF Physical CIM Model October 1999 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 Directory Access Protocol (v3): Attribute Syntax Defini- tions," 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 Model", September 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 for the DMTF Application CIM Model", October 1999. 5. Author's Addresses Ryan Moats Jerry Maziarski John Strassner 15621 Drexel Circle Room C3-3Z01 Cisco Systems, Bldg 1 Omaha, NE 68135 200 S. Laurel Ave. 170 West Tasman Drive USA Middletown, NJ 07748 San Jose, CA 95134 E-mail: jayhawk@att.com USA E-mail: johns@cisco.com E-mail: gfm@qsun.att.com Expires 4/30/00 [Page 32]