Internet-Draft Ryan Moats draft-moats-dmtf-core-ldap-00.txt Gerald Maziarski Expires in six months AT&T John Strassner cisco Systems September 1999 LDAP Schema for the DMTF Core CIM Model Filename: draft-moats-dmtf-core-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 core schema for the DMTF CIM Core model version 2.2 [4]. 1. Introduction This draft presents a LDAPv3 [1,2] schema for the DMTF CIM Core 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 3/31/99 [Page 1]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 class. Other definitions are also provided when necessary. While this approach was chosen to minimize the number of DN pointers stored in the schema, some pointer dereferencing is necessary. While not explicitly stated, all DN pointers are assumed to support the extended matching rule defined in [3]. Attribute names for DN pointers follow the convention that a single pointer to "foo" is named "fooRef" while an array of pointers would be named "fooRefs." Note: all OIDs are place holders, and OIDs in definitions have been replaced by names for clarity. 2.1 dmtfManagedSystemElement Class This is the base class for the system element hierarchy. Any distinguishable component of a system is a candidate for inclusion in this class. Examples of this are software components, such as files; and devices, such as disk drives and controllers, and physical components such as chips and cards. The dmtfManagedSystemElement class supports five attributes: caption, description, installDate, name and status. The caption attribute is a short textual description (one-line string) of the object. The description attribute provides a textual description of the object. The installDate attribute is a date-time value showing when the object was installed. The name attribute defines the label by which the object is known. In subclasses, this attribute can be used as a RDN. The status attribute is a string showing the current status of the object. ( <oid-at1> NAME 'caption' DESC 'short textual description of the object' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at2>NAME 'description' DESC 'a textual description of the object' SYNTAX string SINGLE-VALUE ) ( <oid-at3> NAME 'installDate' DESC 'A datetime value showing when the object was installed. A lack of a value does not show that the object is not installed.' SYNTAX generalizedTime SINGLE-VALUE ) ( <oid-at4> NAME 'name' Expires 3/31/99 [Page 2]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 DESC 'The Name property defines the label by which the object is known. When subclassed, the Name property can be overridden to be a Key property.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at5> NAME 'status' DESC 'A string showing the current status of the object. Various operational and non-operational statuses are defined.' SYNTAX string{10} SINGLE-VALUE ) ( <oid-oc1> NAME 'dmtfManagedSystemElement' DESC 'the base class for the System Element hierarchy' SUP top ABSTRACT MUST (caption $ description $ installDate $ name $ status) ) 2.2 dmtfCollectionOfMSEs This object allows the grouping of dmtfManagedSystemElement objects for associating settings and configurations. It is abstract to require further definition and semantic refinement in subclasses. As this object does not carry any state or status information, it only represents a grouping or 'bag' of elements. So, it is incorrect to subclass groups that have state/status from this class - an example is dmtfRedundancyGroup (which is correctly subclassed from dmtfLogicalElement). Collections typically aggregate 'like' objects, and represent an optimization. Without collections, one is forced to define individual associations, to tie settings and configuration objects to individual dmtfManagedSystemElements. There may be much duplication in assigning the same setting to multiple objects. In addition, using this object allows the determination that the setting and configuration associations are indeed the same for the collection's members. This information would otherwise be obtained by defining the collection in a proprietary way, and then querying the associations to determine if the collection set is completely covered. This class defines a new attribute collectionID and reuse the previously defined attributes description and caption. ( <oid-at6> NAME 'collectionID' DESC 'The identification of the Collection object. Expires 3/31/99 [Page 3]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 When subclassed, the CollectionID property can be overridden to be a RDN' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc2> NAME 'dmtfCollectionOfMSEs' DESC 'Parent class of collections of MSEs' SUP top ABSTRACT MUST (collectionID $ caption $ description) ) 2.3 dmtfCollectedMSEsAuxClass This auxiliary class represents a generic association used to establish the members of the grouping object, dmtfCollectionOfMSEs. It defines the attributes collectionRefs (which point to dmtfCollectionOfMSEs) and memberRefs (which point to dmtfManagedSystemElements). ( <oid-at7> NAME 'collectionRef' DESC 'The grouping or "bag" object that represents the Collection. May be used as an RDN.' SYNTAX DN SINGLE-VALUE ) ( <oid-at8> NAME 'memberRefs' DESC 'The members of the Collection. May be used as an RDN.' SYNTAX DN ) ( <oid-oc3> NAME 'dmtfCollectedMSEsAuxClass' DESC 'generic association used to establish the members of the grouping object, CollectionOfMSEs.' SUP top AUXILIARY MUST (collectionRef $ memberRefs) ) 2.4 dmtfCollectedCollectionsAuxClass This association represents that a dmtfCollectionOfMSEs may itself be contained in another dmtfCollectionOfMSEs object. It reuses collectionRefs and defines and collectionInCollectionRefs. ( <oid-at9> NAME 'collectionInCollectionRefs' DESC 'The "collected" collection. May be used as an RDN.' SYNTAX DN ) Expires 3/31/99 [Page 4]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( <oid-oc4> NAME 'dmtfCollectedCollectionsAuxClass' DESC 'aggregation association representing that a CollectionOfMSEs may itself be contained in a CollectionOfMSEs.' SUP top AUXILIARY MUST (collectionRefs $ collectionInCollectionRefs) ) 2.5 dmtfPhysicalElement class This class acts as the base class for any component of a system that has a distinct physical identity. Instances of this class can be defined in terms of labels that can be physically attached to the object. All processes, files, and logical devices are considered not to be physical elements. For example, it is not possible to attach a label to a modem. It is only possible to attach a label to the card that implements the modem. The same card could also implement a LAN adapter. This is an example of a single physical element (the card) hosting more than one logical device. This class has the following attributes: creationClassName, manufacturer, model, sKU, serialNumber, tag, version, partNumber, otherIdentifyingInfo and poweredOn. The creationClassName attribute shows the name of the class or the subclass used in the creation of an instance. The manufacturer attribute contains the name of the organization responsible for producing this physical element and the partNumber attribute stores that manufacturer's part number of the physical element. The model, version and serialNumber attributes are self-explanatory. The stock keeping unit number of the physical element is contained in the sKU attribute. The tag attribute provides an arbitrary string used to identify the physical element. Other identifying information (beyond that stored in the tag attribute) is stored in the otherIdentifyingInfo attribute. Finally, the poweredOn attribute shows if the physical element is currently powered on or not. In this class, the attributes creationClassName and tag may be used as a RDN. ( <oid-at10> NAME 'creationClassName' DESC 'CreationClassName shows the name of the class or the subclass used in the creation of an instance. When used with the other key properties of this class, this property allows all instances of this class and its subclasses to be uniquely identified. May be used as a RDN.' SYNTAX string{256} SINGLE-VALUE ) Expires 3/31/99 [Page 5]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( <oid-at11> NAME 'manufacturer' DESC 'The name of the organization responsible for producing the PhysicalElement.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at12> NAME 'model' DESC 'The name by which the PhysicalElement is generally known.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at13> NAME 'sKU' DESC 'The stock keeping unit number for this PhysicalElement.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at14> NAME 'serialNumber' DESC 'A manufacturer-allocated number used to identify the PhysicalElement.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at15> NAME 'tag' DESC 'An arbitrary string that uniquely identifies the PhysicalElement and serves as the Element's key. The Tag property can contain information such as asset tag or serial number data. The key for PhysicalElement is placed high in the object hierarchy to independently identify the hardware/entity, regardless of physical placement in or on Cabinets, Adapters, etc. May be used as a RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at16> NAME 'version' DESC 'A string showing the version of the PhysicalElement.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at17> NAME 'partNumber' DESC 'The part number assigned by the organization responsible for producing or manufacturing the PhysicalElement.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at18> NAME 'otherIdentifyingInfo' DESC 'OtherIdentifyingInfo captures additional data, beyond asset tag information, that could be used to identify a Expires 3/31/99 [Page 6]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 PhysicalElement. One example is bar code data associated with an Element that also has an asset tag. Note that if only bar code data is available and is unique/able to be used as an Element key, this property would be NULL and the bar code data used as the class key, in the Tag property.' SYNTAX string SINGLE-VALUE ) ( <oid-at19> NAME 'poweredOn' DESC 'Boolean showing that the PhysicalElement is powered on (TRUE), or is currently off (FALSE).' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc5> NAME 'dmtfPhysicalElement' DESC 'base class for any component of a system that has a distinct physical identity' SUP dmtfManagedSystemElement ABSTRACT MUST (creationClassName $ manufacturer $ model $ sKU $ serialNumber $ tag $ version $ partNumber $ otherIdentifyingInfo $ poweredOn) ) 2.6 dmtfLogicalElement Class This class is the base class for all the components of a system that represent abstract system components, such as files, processes, or system capabilities as logical devices. This class defines no additional attributes to those inherited from dmtfManagedSystemElement ( <oid-oc6> NAME 'dmtfLogicalElement' DESC 'base class for all the components of a System that represent abstract system components, such as Files, Processes, or system capabilities as Logical Devices.' SUP dmtfManagedSystemElement ABSTRACT ) 2.7 dmtfLogicalIdentityAuxClass This auxiliary class represents an abstract and generic association, showing that two dmtfLogicalElements represent different aspects of the same underlying entity. This relationship conveys what could be defined with multiple inheritance. It is restricted to the 'logical' aspects of a dmtfManagedSystemElement. In most scenarios, the identity relationship is determined by the equivalence of keys or Expires 3/31/99 [Page 7]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 some other identifying properties of the related elements. The association should only be used in well understood scenarios. This is why the association is abstract - allowing more concrete definition and clarification in subclasses. This class defines two attributes: systemElementRefs and sameElementRefs. ( <at-21> NAME 'systemElementRefs' DESC 'represents one aspect of the Logical Element' SYNTAX DN ) ( <at-22> NAME 'sameElementRefs' DESC 'represents an alternate aspect of the System entity' SYNTAX DN ) ( <oid-oc7> NAME 'dmtfLogicalIdentityAuxClass' DESC 'an abstract and generic association, showing that two LogicalElements represent different aspects of the same underlying entity. ' SUP top AUXILIARY MUST (systemElementRefs $ sameElementRefs) ) 2.8 dmtfConfiguration Class This object allows the grouping of sets of parameters (defined in dmtfSetting objects) and dependencies for one or more managed system elements. The configuration object represents a certain behavior, or a desired functional state for the managed system elements. The desired functional state is typically driven by external requirements such as time or location. For example, to connect to a Mail System from 'home', a dependency on a modem exists, but a dependency on a network adapter exists at 'work'. Settings for the pertinent logical devices can be defined and aggregated by the configuration. Therefore, two 'Connect to Mail' configurations may be defined grouping the relevant dependencies and setting objects. This class uses the following attributes: name, caption, and description. Name holds the label by which the object is known, and may be used as a RDN. Description holds the textual description of the object, which is summarized in the caption attribute. ( <oid-oc8> NAME 'dmtfConfiguration' DESC 'allows the grouping of sets of parameters and dependencies for one or more dmtfManagedSystemElements.' SUP top MUST (name $ caption $ description) Expires 3/31/99 [Page 8]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ) 2.9 dmtfConfigurationComponentAuxClass This association aggregates 'lower-level' configuration objects into a 'high-level' configuration. This enables the assembly of complex configurations by grouping together simpler ones. ( <oid-at20> NAME 'configGroupRefs' DESC 'The Configuration that aggregates additional Configurations. May be used as an RDN.' SYNTAX DN ) ( <oid-at21> NAME 'configComponentRefs' DESC 'A Configuration that is part of a "higher-level" Configuration. May be used as an RDN.' SYNTAX DN ) ( <oid-oc9> NAME 'dmtfConfigurationComponentAuxClass' DESC 'aggregates lower-level Configuration objects into a high-level Configuration.' SUP top AUXILIARY MUST (configGroupRefs $ configComponentRefs) ) 2.10 dmtfElementConfigurationAuxClass This association relates a configuration object to one or more managed system elements. The configuration object represents a certain behavior, or a desired functional state for the associated managed system elements.' Two attributes are defined by this class: dmtfManagedSystemElementRefs and dmtfConfigurationRefs. ( <oid-at22> NAME 'elementRefs' DESC 'The ManagedSystemElements.' SYNTAX DN ) ( <oid-at23> NAME 'configurationRefs' DESC 'The Configuration objects that groups the Settings and dependencies associated with the ManagedSystemElement.' SYNTAX DN ) Expires 3/31/99 [Page 9]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( <oid-oc10> NAME 'dmtfElementConfigurationAuxClass' DESC 'association relating a Configuration object to one or more ManagedSystemElements' SUP top AUXILIARY MUST (elementRefs $ configurationRefs) ) 2.11 dmtfCollectionConfigurationAuxClass This auxiliary class relates a dmtfConfiguration object to one or more dmtfCollectionOfMSEs objects. The dmtfConfiguration object represents a certain behavior, or a desired functional state for the associated collection. It reuses the collectionRefs and configurationRefs attributes. ( <oid-oc11> NAME 'dmtfCollectionConfigurationAuxClass' DESC 'This association relates a Configuration object to one or more CollectionOfMSEs objects.' SUP top AUXILIARY MUST (collectionRefs $ configurationRefs) ) 2.12 dmtfSetting Class This class represents configuration-related and operational parameters for one or more managed system element(s). A managed system element may have multiple setting objects associated with it. The current operational values for an element's parameters are reflected by properties in the element itself or by properties in its associations. These properties do not have to be the same values present in the setting object. For example, a modem may have a setting baud rate of 56Kb/sec but be operating at 19.2Kb/sec. This class uses the description and caption attributes defined above and defines the attribute settingID, which is the identifier for the setting object. ( <oid-at24> NAME 'settingID' DESC 'The identifier by which the Setting object is known.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc12> NAME 'dmtfSetting' DESC 'configuration-related and operational parameters for one or more ManagedSystemElement(s).' SUP top ABSTRACT MUST (settingID $ caption $ description) ) Expires 3/31/99 [Page 10]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 2.13 dmtfElementSettingAuxClass Association This auxiliary class represents the association between managed system elements and the setting class(es) defined for them. It reuses the elementRefs attribute and defines the attribute settingRefs. ( <oid-at25> NAME 'settingRefs' DESC 'The setting objects associated with the managed system elements.' SYNTAX DN ) ( <oid-oc13> NAME 'dmtfElementSettingAuxClass' DESC 'association between ManagedSystemElements and the Setting class(es) defined for them.' SUP top AUXILIARY MUST (elementRefs $ settingRefs) ) 2.14 dmtfDefaultSettingAuxClass This auxiliary class represents the association between a dmtfManagedSystemElement and the single dmtfSetting class that is defined to be the default setting for this element. ( <oid-at26> NAME 'defaultSettingRefs' DESC 'default setting to use for this class SYNTAX DN ) ( <oid-oc14> NAME 'dmtfDefaultSettingAuxClass' DESC 'represents the association between a ManagedSystemElement and the single Setting class that is defined to be the default setting for this Element.' SUP dmtfElementSettingAuxClass AUXILIARY MUST (defaultSettingRefs) ) 2.15 dmtfSettingContextAuxClass Association This auxiliary class associates a setting with one or more configuration objects. For example, a network adapter's settings could change based on the site/network to which its hosting computer system is attached. This class uses the dmtfConfigurationRefs and dmtfSettingRefs attributes previously defined. ( <oid-at27> NAME 'contextRefs' DESC 'The configuration object that aggregates settings' Expires 3/31/99 [Page 11]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 SYNTAX DN ) ( <oid-oc15> NAME 'dmtfSettingContextAuxClass' DESC 'associates a Setting with one or more Configuration objects.' SUP top AUXILIARY MUST (contextRefs $ settingRefs) ) 2.16 dmtfCollectionSettingAuxClass This auxiliary class represents the association between a dmtfCollectionOfMSEs class and the dmtfSetting class(es) defined for them. It reuses the collectionRefs and settingRefs attributes. ( <oid-oc16> NAME 'dmtfCollectionSettingAuxClass' DESC 'association between a CollectionOfMSEs class and the Setting class(es) defined for them.' SUP top AUXILIARY MUST (collectionRefs $ settingRefs) ) 2.17 dmtfSystem Class This class is a logical element that aggregates an enumerable set of managed system elements and operates as a functional whole. Within any particular subclass of system, there is a well-defined list of managed system element classes whose instances must be aggregated. This class uses the attributes creationClassName and name previously defined and defines the attributes nameFormat, primaryOwnerContact, primaryOwnerName, and roles. The nameFormat attribute identifies how the system name was generated. Primary owner information (name and contact) are stored in the primaryOwnerName and primaryOwnerContact information, respectively. The roles attributes is an array of strings specifying the roles this system plays. ( <oid-at28> NAME 'nameFormat' DESC 'identifies how the System name was generated, using the subclass heuristic.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at29> NAME 'primaryOwnerContact' DESC 'A string that provides information on how the primary system owner can be reached (e.g. phone number, email address, ...' SYNTAX string{256} SINGLE-VALUE Expires 3/31/99 [Page 12]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ) ( <oid-at30> NAME 'primaryOwnerName' DESC 'The name of the primary system owner.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at31> NAME 'roles' DESC 'what roles this System plays in the IT-environment.' SYNTAX string ) ( <oid-oc17> NAME 'dmtfSystem' DESC 'A Logical Element that aggregates an enumerable set of Managed System Elements.' SUP dmtfLogicalElement ABSTRACT MUST (creationClassName $ name $ nameFormat $ primaryOwnerContact $ primaryOwnerName $ roles) ) 2.18 dmtfComputerSystem Class This class is derived from dmtfSystem and represents a special collection of managed system elements that provide compute capabilities. Thus, it serves as aggregation point to associate one or more of the following elements: file systems, operating systems, processors and memory (volatile and/or non-volatile storage). This class overrides the nameFormat attribute to show the CIM V2 System model heuristic for determining the computer system's name. It also defines the attributes otherIdentifyingInfo, identifyingDescriptions, and dedicated. ( <oid-at32> NAME 'otherIdentifyingInfo' DESC 'captures additional data, beyond system name information, that could be used to identify a computer system.' SYNTAX string{256} ) ( <oid-at33> NAME 'identifyingDescriptions' DESC 'An array of free-form strings providing explanations and details behind the entries in the otherIdentifyingInfo array.' SYNTAX string ) ( <oid-at34> NAME 'dedicated' DESC 'Enumeration showing whether the ComputerSystem is a special-purpose System (ie, dedicated to a particular use), Expires 3/31/99 [Page 13]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 versus being "general purpose".' SYNTAX integer ) ( <oid-oc18> NAME 'dmtfComputerSystem' DESC 'a special collection of ManagedSystemElements that provide compute capabilities' SUP dmtfSystem ABSTRACT MUST (otherIdentifyingInfo $ identifyingDescriptions $ dedicated) ) 2.19 dmtfLogicalDevice Class This class represents an abstraction or emulation of a hardware entity, that may or may not be realized in physical hardware. Any characteristics of a logical device that are used to manage its operation or configuration are contained in, or associated with, this object. This object defines the attributes systemCreationClassName, systemName, deviceID, powerManagementSupported, powerManagementCapabilities, availability, statusInfo, lastErrorCode, errorDescription, errorCleared, powerOnHours, totalPowerOnHours and also uses the previously defined creationClassName, otherIdentifyingInfo and identifyingDescriptions. The systemCreationClassName, systemName, lastErrorCode, errorCleared and deviceID attributes are self explanatory and powerManagementSupportd shows whether the device can be power managed. If the device can be power managed, the capabilities for doing so are presented in the powerManagementCapabilities attribute (an array of integers). Allowed values for this attribute are: "Unknown", "Not Supported", "Disabled", "Enabled", "Power Saving Modes Entered Automatically", "Power State Settable", "Power Cycling Supported", and "Timed Power On Supported". The availability attribute contains availability and status of the Device, while statusInfo is an integer showing whether the LogicalDevice is in an enabled (value = 3), disabled (value = 4) or some other (1) or unknown (2) state. If this property does not apply to the LogicalDevice, the value, 5 ("Not Applicable") should be used. ErrorDescirption is a free-form string supplying more information about the error recorded in LastErrorCode, including information on any corrective actions that may be taken. ( <oid-at35> NAME 'systemCreationClassName' DESC 'The scoping System's CreationClassName. May be used as a RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at36> NAME 'systemName' Expires 3/31/99 [Page 14]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 DESC 'The scoping System's Name. May be used as a RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at37> NAME 'deviceID' DESC 'An address or other identifying information to uniquely name the LogicalDevice. May be used as a RDN.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at38> NAME 'powerManagementSupported' DESC 'shows if the Device can be power managed - ie, put into a power save state.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at39> NAME 'powerManagementCapabilities' DESC 'Indicates the specific power-related capabilities of a LogicalDevice.' SYNTAX integer ) ( <oid-at40> NAME 'availability' DESC 'The availability and status of the Device.' SYNTAX integer SINGLE-VALUE ) ( <oid-at41> NAME 'statusInfo' DESC 'logical device state' SYNTAX integer SINGLE-VALUE ) ( <oid-at42> NAME 'lastErrorCode' DESC 'the last error code reported by the LogicalDevice.' SYNTAX integer SINGLE-VALUE ) ( <oid-at43> NAME 'errorDescription' DESC 'more information about the error recorded in LastErrorCode' SYNTAX string SINGLE-VALUE ) ( <oid-at44> NAME 'errorCleared' DESC 'shows that the error reported in LastErrorCode is now cleared.' SYNTAX boolean SINGLE-VALUE ) Expires 3/31/99 [Page 15]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( <oid-at45> NAME 'powerOnHours' DESC 'The number of consecutive hours that this Device has been powered, since its last power cycle.' SYNTAX integer SINGLE-VALUE ) ( <oid-at46> NAME 'totalPowerOnHours' DESC 'The total number of hours that this Device has been powered.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc19> NAME 'dmtfLogicalDevice' DESC 'An abstraction or emulation of a hardware entity' SUP dmtfLogicalElement ABSTRACT MUST (systemCreationClassName $ systemName $ creationClassName $ deviceID $ powerManagementSupported $ powerManagementCapabilities $ availability $ statusInfo $ lastErrorCode $ errorDescription $ errorCleared $ otherIdentifyingInfo $ powerOnHours $ totalPowerOnHours $ identifyingDescriptions) ) Although systemCreationClassName and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 1 NAME 'dmtfLogicalDeviceStructureRule2' FORM dmtfLogicalDeviceNameForm1 SUP 3 4 ) ( 2 NAME 'dmtfLogicalDeviceStructuralRule2' FORM dmtfLogicalDeviceNameForm2 SUP 3 4 ) ( <oid-nf1> NAME 'dmtfLogicalDeviceNameForm1' OC dmtfLogicalDevice MUST (creationClassName) ) ( <oid-nf2> NAME 'dmtfLogicalDeviceNameForm2' OC dmtfLogicalDevice MUST (deviceID) ) ( <oid-nf3> NAME 'dmtfSystemNameForm1' Expires 3/31/99 [Page 16]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 OC dmtfSystem MUST (creationClassName) ) ( <oid-nf4> NAME 'dmtfSystemNameForm2' OC dmtfSystem MUST (name) ) ( 3 NAME 'dmtfSystemStructureRule1' FORM dmtfSystemNameForm1 ) ( 4 NAME 'dmtfSystemStructureRule2' FORM dmtfSystemNameForm1 ) 2.20 dmtfService Class This class represents a Logical Element that contains the information necessary to represent and manage the functionality provided by a device and/or software feature. A service is a general-purpose object to configure and manage the implementation of functionality. It is not the functionality itself. This class uses the systemCreationClassName, systemName, creationClassName and name attributes previously defined. It also defines the attributes startMode and started. The startMode attribute shows whether a service is automatically started or only started on request, while started shows if the service has been started or stopped. ( <oid-at47> NAME 'startMode' DESC 'shows whether the Service is automatically started by a System, Operating System, etc. or only started on request.' SYNTAX string{10} SINGLE-VALUE ) ( <oid-at48> NAME 'started' DESC 'boolean showing whether the Service has been started (TRUE), or stopped (FALSE).' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc20> NAME 'dmtfService' DESC 'information necessary to represent and manage the functionality provided by a Device and/or SoftwareFeature.' Expires 3/31/99 [Page 17]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 SUP dmtfLogicalElement ABSTRACT MUST (creationClassName $ name $ startMode $ started $ systemCreationClassName $ systemName) ) Although systemCreationClassName and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 5 NAME 'dmtfServiceStructureRule1' FORM dmtfServiceNameForm1 SUP 3 4 ) ( <oid-nf5> NAME 'dmtfServiceNameForm1' OC dmtfService MUST (creationClassName) ) ( 6 NAME 'dmtfServiceStructureRule2' FORM dmtfServiceNameForm2 SUP 3 4 ) ( <oid-nf6> NAME 'dmtfServiceNameForm' OC dmtfService MUST (name) ) 2.21 dmtfServiceAccessPoint Class This class represents the ability to use or invoke a service. Access points represent that a service is made available to other entities for use. This class uses the previously defined attributes creationClassName, name, systemCreationClassName and systemName. ( <oid-oc21> NAME 'dmtfServiceAccessPoint' DESC 'representation of the ability to use or invoke a Service' SUP dmtfLogicalElement ABSTRACT MUST (creationClassName $ name $ systemCreationClassName $ systemName) ) Although systemCreationClassName and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 7 NAME 'dmtfServiceAccessPointStructureRule1' FORM dmtfServiceAccessPointNameForm1 SUP 3 4 Expires 3/31/99 [Page 18]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ) ( <oid-nf7> NAME 'dmtfServiceAccessPointNameForm1' OC dmtfServiceAccessPoint MUST (creationClassName) ) ( 8 NAME 'dmtfServiceAccessPointStructureRule2' FORM dmtfServiceAccessPointNameForm2 SUP 3 4 ) ( <oid-nf8> NAME 'dmtfServiceAccessPointNameForm2' OC dmtfServiceAccessPoint MUST (name) ) 2.22 dmtfDependencyAuxClass Association This class represents a generic association used to establish dependency relationships between objects. It defines two attributes antecedentRefs and dependentRefs, which must both point to dmtfManagedSystemElement objects. ( <oid-at49> NAME 'antecedentRefs' DESC 'the independent objects in this association.' SYNTAX DN ) ( <oid-at50> NAME 'dependentRefs' DESC 'the object dependent on the antecedent.' SYNTAX DN ) ( <oid-oc22> NAME 'dmtfDependencyAuxClass' DESC 'generic association used to establish dependency relationships between objects.' SUP top AUXILIARY MUST (antecedentRefs $ dependentRefs) ) 2.23 dmtfDependencyContextAuxClass Association This relationship associates a dependency with one or more configuration objects. For example, a computer system's dependencies could change based on the site/network to which the system is attached. Expires 3/31/99 [Page 19]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 This class reuses the contextRefs attribute defined previously and defines the attribute dependencyRefs, which points to a set of dmtfDependency objects. ( <oid-at51> NAME 'dependencyRefs' DESC 'An aggregated Dependency.' SYNTAX DN ) ( <oid-oc23> NAME 'dmtfDependencyContextAuxClass' DESC 'association of Dependency with one or more Configurations' SUP top AUXILIARY MUST (dmtfConfigurationRefs $ dmtfDependencyRefs) ) 2.24 dmtfServiceAccessBySAPAuxClass Association This association identifies the access points for a service. For example, a printer may be accessed by Netware, MacIntosh or Windows service access points, potentially hosted on different systems. In this association, antecedentRef points to dmtfService objects and dependentRef points to dmtfServiceAccessPoint objects. ( <oid-oc24> NAME 'dmtfServiceAccessBySAPAuxClass' DESC 'identifies the access points for a service' SUP dmtfDependencyAuxClass AUXILIARY ) 2.25 dmtfServiceServiceDependencyAuxClass Association This is an association between two services, showing that the latter is required to be present, required to have completed, or must be absent for the former Service to provide its functionality. For example, boot Services may be dependent on underlying BIOS disk and initialization services. For initialization services, the boot service is simply dependent on the initialization services completing. In this class, both antecedentRefs and dependentRefs point to dmtfService objects. In addition, this class stores the type of dependency in the typeOfDependency attribute. Allowed values for typeOfDepencency are: "Unknown", "Other", "Service Must Have Completed", "Service Must Be Started", and "Service Must Not Be Started". ( <oid-at52> NAME 'typeOfDependency' DESC 'type of Service to Service dependency.' SYNTAX integer SINGLE-VALUE Expires 3/31/99 [Page 20]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ) ( <oid-oc25> NAME 'dmtfServiceServiceDependencyAuxClass' DESC 'association between two services' SUP dmtfDependencyAuxClass AUXILIARY MUST (typeOfDependency) ) 2.26 dmtfServiceSAPDependencyAuxClass Association This class is an association between a service and a service access point showing that the referenced SAP is used by the service to provide its functionality. For example, boot services may invoke BIOS disk services (interrupts) to function. In this class, antecedentRefs point to dmtfServiceAccessPoint objects and dependentRefs point to dmtfService objects. ( <oid-oc26> NAME 'dmtfServiceSAPDependencyAuxClass' DESC 'association between a Service and a ServiceAccessPoint' SUP dmtfDependencyAuxClass AUXILIARY ) 2.27 dmtfSAPSAPDependencyAuxClass Association This class is an association between two service access points showing that the latter is required in order for the former to use or connect with its service. For example, to print at a network printer, local print access points must use underlying network-related SAPs, or protocol endpoints, to send the print request. In this class, both antecedentRefs and dependentRefs point to dmtfServiceAccessPoint objects. ( <oid-oc27> NAME 'dmtfSAPSAPDependencyAuxClass' DESC 'association between two ServiceAccessPoints' SUP dmtfDependencyAuxClass AUXILIARY ) 2.28 dmtfProvidesServiceToElementAuxClass This association is used to describe that dmtfManagedSystemElements may be dependent on the functionality of one or more Services. In this class antecedentRefs point to dmtfService objects and dependentRefs point to dmtfManagedSystemElement objects. ( <oid-oc28> NAME 'dmtfProvidesServiceToElementAuxClass' DESC 'this association is used to describe that Expires 3/31/99 [Page 21]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ManagedSystemElements may be dependent on the functionality of one or more Services.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.29 dmtfRealizesAuxClass Association This association defines the mapping between a logical device and the physical component that implements the device. In this class, antecedentRefs points to dmtfPhysicalElement objects and dependentRefs points to dmtfLogicalElement objects. ( <oid-oc29> NAME 'dmtfRealizesAuxClass' DESC 'mapping between a Logical Device and the physical component that implements the Device.' SUP dmtfDependencyAuxClass AUXILIARY ) 2.30 dmtfComponentAuxClass Association This class is a generic association used to establish 'part of' relationships between managed system elements. For example, the system component association defines parts of a system. This class defines two attributes: groupRefs, which holds the parent elements of the association and partRefs, which holds the children elements of the association. In this class, both attributes point to dmtfManagedSystemElement objects. ( <oid-at53> NAME 'groupRefs' DESC 'The parent elements in the association.' SYNTAX DN ) ( <oid-at54> NAME 'partRefs' DESC 'The children elements in the association.' SYNTAX DN ) ( <oid-oc30> NAME 'dmtfComponentAuxClass' DESC 'generic association used to establish part of relationships between managed system elements.' SUP top AUXILIARY MUST (groupRefs $ partRefs) ) Expires 3/31/99 [Page 22]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 2.31 dmtfSystemComponentAuxClass Association This class is a specialization of the dmtfComponentAuxClass association that establishes part of relationships between a system and the managed system elements of which it is composed. In this class, groupRefs points to dmtfSystem objects while partRefs continues to dmtfManagedSystemElement objects. ( <oid-oc31> NAME 'dmtfSystemComponentAuxClass' DESC 'specialization of dmtfComponent handling relationships between a System and the Managed System Elements of which it is composed.' SUP dmtfComponentAuxClass AUXILIARY ) 2.32 dmtfServiceComponentAuxClass This auxiliary class models a set of subordinate services that are aggregated together to form a higher-level service. In it, both groupRefs and partRefs both point to dmtfService objects. ( <oid-oc32> NAME 'dmtfServiceComponentAuxClass' DESC 'The ServiceComponent aggregation models a set of subordinate Services that are aggregated together to form a higher-level service.' SUP dmtfComponentAuxClass AUXILIARY ) 2.33 dmtfProduct Class This concrete class that is a collection of physical elements, software features and/or other products, acquired as a unit. Acquisition implies an agreement between supplier and consumer that may have implications to product licensing, support and warranty. This class uses the previously defined attributes caption, description, name, sKU, and version and defines attributes identifyingNumber and vendor. The identifyingNumber provides product identification, while vendor contains the name of the product's supplier. Both of these attributes may be used as a RDN. ( <oid-at55> NAME 'identifyingNumber' DESC 'Product identification such as a serial number on software or a die number on a hardware chip.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at56> NAME 'vendor' Expires 3/31/99 [Page 23]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 DESC 'The name of the supplier.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc33> NAME 'dmtfProduct' DESC 'collection of PhysicalElements, SoftwareFeatures and/or other Products, acquired as a unit.' SUP top MUST (caption $ description $ identifyingNumber $ name $ sKUNumber $ vendor $ version) ) 2.34 dmtfProductParentChildAuxClass Association The association defines a parent child hierarchy among products. For example, a product may come bundled with other products. This class defines two attributes: parentRefs (the parent of the association) and childRefs (the children of the association). In this class, both attributes point to dmtfProduct objects. ( <oid-at57> NAME 'parentRefs' DESC 'The parent Product in the association.' SYNTAX DN ) ( <oid-at58> NAME 'childRefs' DESC 'The child Product in the association.' SYNTAX DN ) ( <oid-oc34> NAME 'dmtfProductParentChildAuxClass' DESC 'parent child hierarchy among Products' SUP top AUXILIARY MUST (parentRefs $ childRefs) ) 2.35 dmtfCompatibleProductAuxClass Association This association between products can show a wide variety of information. For example, it can show that the two referenced products interoperate, that they can be installed together, that one can be the physical container for the other, etc. The string attribute compatibilityDescription, defines how the products interoperate or are compatible. This class also defines attributes productRefs and compatibleProductRefs, both of which point to dmtfProduct objects. ( <oid-at59> NAME 'productRefs' Expires 3/31/99 [Page 24]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 DESC 'The Product for which compatible offerings are defined.' SYNTAX DN ) ( <oid-at60> NAME 'compatibleProductRefs' DESC 'The compatible Product.' SYNTAX DN ) ( <oid-at61> NAME 'compatibilityDescription' DESC 'free-form string defining how the two referenced product interoperate' SYNTAX string SINGLE-VALUE ) ( <oid-oc35> NAME 'dmtfCompatibleProductAuxClass' DESC 'an association between Products' SUP top AUXILIARY MUST (productRefs $ compatibleProductRefs $ compatibilityDescription) ) 2.36 dmtfProductProductDependencyAuxClass Association This association is between two products, showing that one must be installed, or must be absent, for the other to function. This is conceptually equivalent to the service to service dependency association. This class defines the attributes requiredProductRefs and dependentProductRefs, and uses the previously defined typeOfDependency attribute. The reference attributes both point to dmtfProduct objects. ( <oid-at62> NAME 'requiredProductRefs' DESC 'The required Product.' SYNTAX DN ) ( <oid-at63> NAME 'dependentProductRefs' DESC 'The Product that is dependent on another Product.' SYNTAX DN ) ( <oid-oc36> NAME 'dmtfProductProductDependencyAuxClass' DESC 'dependency association between two products' SUP top AUXILIARY MUST (requiredProductRefs $ dependentProductRefs $ typeOfDependency) Expires 3/31/99 [Page 25]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ) 2.37 dmtfSupportAccess Class This class defines how to obtain help for a product. It defines attributes communicationInfo (providing information about the communicationMode), communicationMode (defines the form of communication available), locale (defines the geographic region), and supportAccessId (arbitrary, free form string that may be used as a RDN). In addition, it uses the previously defined attribute description. ( <oid-at64> NAME 'communicationInfo' DESC 'provides the details of the CommunicationMode. For example, if the CommunicationMode is phone, CommunicationInfo specifies the phone number to be called.' SYNTAX string SINGLE-VALUE ) ( <oid-at65> NAME 'communicationMode' DESC 'CommunicationMode defines the form of communication in order to obtain support. For example, phone communication (value=2), fax (3) or email (8) can be specified.' SYNTAX integer SINGLE-VALUE ) ( <oid-at66> NAME 'locale' DESC 'Locale defines the geographic region and/or language dialect to which this Support resource pertains.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at67> NAME 'supportAccessId' DESC 'SupportAccessID is an arbitrary, free form string defined by the Product Vendor or by the organization that deploys the Product. This property, since it is a key, should be unique throughout the enterprise. May be used as a RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc37> NAME 'dmtfSupportAccess' DESC 'defines how to obtain help for a Product.' SUP top MUST (communicationInfo $ communicationMode $ description $ locale $ supportAccessId) ) Expires 3/31/99 [Page 26]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 2.38 dmtfProductSupportAuxClass Association This auxiliary class represents the association between products and support access that conveys how support is obtained for the product. This is a many-to-many relationship, implying that various types of support are available for a product, and that the same support object can provide help for multiple products. This class defines two attributes that are self-explanatory. ( <oid-at68> NAME 'productRefs' DESC 'The Product.' SYNTAX DN ) ( <oid-at69> NAME 'supportRefs' DESC 'Support for the Product.' SYNTAX DN ) ( <oid-oc38> NAME 'dmtfProductSupportAuxClass' DESC 'the association between Product and SupportAccess that conveys how support is obtained for the Product.' SUP top AUXILIARY MUST (productRefs $ supportRefs) ) 2.39 dmtfFRU Class This class is a vendor-defined collection of products and/or physical elements that is associated with a product for supporting, maintaining or upgrading that product at the customer's location. FRU is an acronym for 'field replaceable unit'. This class uses the previously defined caption, description, identifyingNumber, vendor, and name attributes and defines the attributes fRUNumber (FRU ordering information), and revisionLevel (FRU's revision level.) ( <oid-at70> NAME 'fRUNumber' DESC 'FRU ordering information. May be used as a RDN' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at71> NAME 'revisionLevel' DESC 'The FRU's revision level.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-oc39> NAME 'dmtfFRU' DESC 'field replacible unit' Expires 3/31/99 [Page 27]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 SUP top MUST (caption $ description $ fRUNumber $ identifyingNumber $ name $ vendor $ revisionLevel) ) 2.40 dmtfProductFRUAuxClass Association This auxiliary class provides information regarding what product components have been or are being replaced and uses the previously defined attribute dmtfProductRefs. It also defines the attribute fRURefs, which holds the FRU information. ( <oid-at72> NAME 'fRURefs' DESC 'The FRU.' SYNTAX DN ) ( <oid-oc40> NAME 'dmtfProductFRUAuxClass' DESC 'association between Product and FRU that provides information about replacements' SUP top AUXILIARY MUST (productRefs $ fRURefs) ) 2.41 dmtfProductPhysicalElementsAuxClass Association Indicates the physical elements that make up a product. It uses the previously defined dmtfProductsRefs attribute and defines dmtfPhysicalElementRefs. ( <oid-at73> NAME 'componentRefs' DESC 'The PhysicalElement that is a part of the Product.' SYNTAX DN ) ( <oid-oc41> NAME 'dmtfProductPhysicalElementsAuxClass' DESC 'Indicates the PhysicalElements that make up a Product.' SUP top AUXILIARY MUST (productRefs $ componentRefs) ) 2.42 NAME 'dmtfFRUPhysicalElementsAuxClass' This auxiliary class shows the physical elements that make up a FRU and uses previously defined attributes. ( <oid-oc42> NAME 'dmtfFRUPhysicalElementsAuxClass' DESC 'Indicates the PhysicalElements that make up a FRU.' Expires 3/31/99 [Page 28]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 SUP top AUXILIARY MUST (dmtfFRURefs $ dmtfPhysicalElementRefs) ) 2.43 dmtfFRUIncludesProductAuxClass Association This auxiliary class shows that a FRU may be composed of other product(s). It uses previously defined attributes. ( <oid-oc43> NAME 'dmtfFRUIncludesProductAuxClass' DESC 'Indicates that a FRU may be composed of other Product(s).' SUP top AUXILIARY MUST (dmtfFRURefs $ dmtfProductRefs) ) 2.44 dmtfStatisticalInformation Class This root class holds any arbitrary collection of statistical data and/or metrics applicable to one or more managed system elements and uses previously defined attributes. ( <oid-oc44> NAME 'dmtfStatisticalInformation' DESC 'root class for any arbitrary collection of statistical data and/or metrics applicable to one or more ManagedSystemElements.' SUP top ABSTRACT MUST (name $ description $ caption) ) 2.45 dmtfStatisticsAuxClass Association This auxiliary class relates managed system elements to the statistical group(s) that apply to them. The attribute dmtfStatisticalInformationRefs is defined by this class. ( <oid-at74> NAME 'statsRefs' DESC 'The statistic information/object.' SYNTAX DN ) ( <oid-oc45> NAME 'dmtfStatisticsAuxClass' DESC 'association relating ManagedSystemElements to the StatisticalGroup(s) that apply to them.' SUP top AUXILIARY MUST (statsRefs $ elementRefs) ) Expires 3/31/99 [Page 29]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 2.46 dmtfRelatedStatisticsAuxClass Association This auxiliary class defines hierarchies and/or dependencies of related statistical information classes. It defines the attributes statsRefs and relatedStatsRefs, both of which point to dmtfStatisticalInformation objects. ( <oid-at75> NAME 'relatedStatsRefs' DESC 'The related statistics or metrics.' SYNTAX DN ) ( <oid-oc46> NAME 'dmtfRelatedStatisticsAuxClass' DESC 'hierarchies and/or dependencies of related CIM_Statistical Information classes' SUP top AUXILIARY MUST (dmtfStatisticalInformationRefs $ dmtfStatisticalInformationRefs) ) 2.47 dmtfSystemStatisticalInformation class This class provides statistical information associated with a system object or one of its subclasses. This class reuses the attributes systemCreationClassName, systemName, creationClassName, and name. ( <oid-oc47> NAME 'dmtfSystemStatisticalInformation' DESC 'Statistical information associated with a System object or one of its subclasses.' SUP dmtfStatisticalInformation MUST (systemCreationClassName $ systemName $ creationClassName $ name) ) Although systemCreationClassName and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 9 NAME 'dmtfSystemStatisticsStructureRule1' FORM dmtfSystemStatisticalInformationNameForm1 SUP 3 4 ) ( <oid-nf9> NAME 'dmtfSystemStatisticalInformationNameForm1' OC dmtfSystemStatisticalInformation MUST (creationClassName) ) ( 10 NAME 'dmtfSystemStatisticsStructureRule2' FORM dmtfSystemStatisticalInformationNameForm2 Expires 3/31/99 [Page 30]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 SUP 3 4 ) ( <oid-nf10> NAME 'dmtfSystemStatisticalInformationNameForm2' OC dmtfSystemStatisticalInformation MUST (name) ) 2.48 dmtfServiceStatisticalInformation Statistical information associated with a service object or one of its subclasses. This class reuses the attributes systemCreationClassName, systemName, creationClassName, and name. It defines serviceCreationClassName and serviceName. ( <oid-at76> NAME 'serviceCreationClassName' DESC 'The scoping Service's CreationClassName. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at77> NAME 'serviceName' DESC 'The scoping Service's Name. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc48> NAME 'dmtfServiceStatisticalInformation' DESC 'Statistical information associated with a Service object or one of its subclasses.' SUP dmtfStatisticalInformation MUST (systemCreationClassName $ systemName $ serviceCreationClassName $ serviceName $ creationClassName $ name) ) Although systemCreationClassName, serviceCreationClassName, serviceName and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 11 NAME 'dmtfServiceStatisticsStructureRule1' FORM dmtfServiceStatisticalInformationNameForm1 SUP 5 6 ) ( <oid-nf11> NAME 'dmtfServiceStatisticalInformationNameForm1' OC dmtfServiceStatisticalInformation MUST (creationClassName) Expires 3/31/99 [Page 31]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ) ( 12 NAME 'dmtfServiceStatisticsStructureRule2' FORM dmtfServiceStatisticalInformationNameForm2 SUP 5 6 ) ( <oid-nf12> NAME 'dmtfServiceStatisticalInformationNameForm2' OC dmtfServiceStatisticalInformation MUST (name) ) 2.49 dmtfSAPStatisticalInformation Statistical information associated with a service access point object or one of its subclasses. This class reuses the attributes systemCreationClassName, systemName, creationClassName, and name. It further defines the attributes sAPCreationClassName and sAPName. ( <oid-at78> NAME 'sAPCreationClassName' DESC 'The scoping SAP's CreationClassName. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at79> NAME 'sAPName' DESC 'The scoping SAP's Name. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc49> NAME 'dmtfSAPStatisticalInformation' DESC 'Statistical information associated with a service access point object or one of its subclasses.' SUP dmtfStatisticalInformation MUST (systemCreationClassName $ systemName $ sAPCreationClassName $ sAPName $ creationClassName $ name) ) Although systemCreationClassName, sAPCreationClassName, sAPName and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 13 NAME 'dmtfSAPStatisticsStructureRule1' FORM dmtfSAPStatisticalInformationNameForm1 SUP 7 8 ) Expires 3/31/99 [Page 32]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( <oid-nf13> NAME 'dmtfSAPStatisticalInformationNameForm1' OC dmtfSAPStatisticalInformation MUST (creationClassName) ) ( 14 NAME 'dmtfSAPStatisticsStructureRule2' FORM dmtfSAPStatisticalInformationNameForm2 SUP 7 8 ) ( <oid-nf14> NAME 'dmtfSAPStatisticalInformationNameForm2' OC dmtfSAPStatisticalInformation MUST (name) ) 2.50 dmtfDeviceStatisticalInformation Statistical information associated with a logical device or one of its subclasses. This class reuses the attributes systemCreationClassName, systemName, deviceID, creationClassName, name and defines the attribute deviceCreationClassName ( <oid-at80> NAME 'deviceCreationClassName' DESC 'The scoping Device's CreationClassName. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc50> NAME 'dmtfDeviceStatisticalInformation' DESC 'Statistical information associated with a LogicalDevice or one of its subclasses.' SUP dmtfStatisticalInformation MUST (systemCreationClassName $ systemName $ deviceCreationClassName $ deviceID $ creationClassName $ name) ) Although systemCreationClassName, deviceCreationClassName, deviceID and systemName may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 15 NAME 'dmtfDeviceStatisticsStructureRule1' FORM dmtfDeviceStatisticalInformationNameForm1 SUP 1 2 ) ( <oid-nf15> NAME 'dmtfDeviceStatisticalInformationNameForm1' Expires 3/31/99 [Page 33]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 OC dmtfDeviceStatisticalInformation MUST (name) ) ( 16 NAME 'dmtfDeviceStatisticsStructureRule2' FORM dmtfDeviceStatisticalInformationNameForm2 SUP 1 2 ) ( <oid-nf16> NAME 'dmtfDeviceStatisticalInformationNameForm2' OC dmtfDeviceStatisticalInformation MUST (creationClassName) ) 2.51 dmtfPhysicalStatisticalInformation Statistical information associated with a physical element or one of its subclasses. This class defines the attribute physicalCreationClassName and reuses the attributes tag, creationClassName, and name. ( <oid-at81> NAME 'physicalCreationClassName' DESC 'The scoping Element's CreationClassName. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc51> NAME 'dmtfPhysicalStatisticalInformation' DESC 'Statistical information associated with a PhysicalElement or one of its subclasses.' SUP dmtfStatisticalInformation MUST (physicalCreationClassName $ tag $ creationClassName $ name) ) Although physicalCreationClassName, and tag may be used as RDNs for this class, the solution taken in this schema is to require that this class follow the containment and name form rules below. ( 17 NAME 'dmtfPhysicalStatisticsStructureRule1' FORM dmtfPhysicalStatisticalInformationNameForm1 SUP 19 20 ) ( <oid-nf17> NAME 'dmtfPhysicalStatisticalInformationNameForm1' OC dmtfPhysicalStatisticalInformation MUST (name) ) Expires 3/31/99 [Page 34]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( 18 NAME 'dmtfPhysicalStatisticsStructureRule2' FORM dmtfPhysicalStatisticalInformationNameForm2 SUP 19 20 ) ( <oid-nf18> NAME 'dmtfPhysicalStatisticalInformationNameForm2' OC dmtfPhysicalStatisticalInformation MUST (creationClassName) ) ( 19 NAME 'dmtfPhysicalElementStructureRule1' FORM dmtfPhysicalElementNameForm1 ) ( <oid-nf19> NAME 'dmtfPhysicalElementNameForm1' OC dmtfPhysicalElement MUST (creationClassName) ) ( 20 NAME 'dmtfPhysicalElementStructureRule2' FORM dmtfPhysicalElementNameForm2 ) ( <oid-nf20> NAME 'dmtfPhysicalElementNameForm2' OC dmtfPhysicalElement MUST (tag) ) 3. DIT Content Rules The following DIT Content Rules apply to objects in this schema. These content rules reference not only auxiliary classes in this draft but auxiliary classes from other DMTF CIM models [5, 6, 7, 8, 9]. ( <oid-oc1> NAME 'dmtfManagedSystemElementContentRule' DESC 'shows what auxiliary classes may go with the dmtfManagedSystemElement class' AUX (dmtfCollectedMSEsAuxClass $ dmtfProvidesServiceToElementAuxClass $ dmtfElementConfigurationAuxClass $ dmtfRedundancyComponentAuxClass $ dmtfElementSettingAuxClass $ dmtfDependencyAuxClass $ dmtfDependencyAuxClass $ dmtfComponentAuxClass $ dmtfComponentAuxClass $ dmtfSystemComponentAuxClass $ dmtfStatisticsAuxClass $ dmtfActsAsSpareAuxClass) ) ( <oid-oc2> NAME 'dmtfCollectionOfMSEsContentRule' Expires 3/31/99 [Page 35]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 DESC 'shows what auxiliary classes may go with the dmtfCollectionOfMSEs class' AUX (dmtfCollectedMSEsAuxClass $ dmtfCollectedCollectionsAuxClass $ dmtfCollectionConfigurationAuxClass $ dmtfCollectionSettingAuxClass) ) ( <oid-oc5> NAME 'dmtfPhysicalElementContentRule' DESC 'shows what auxiliary classes may go with the dmtfPhysicalElement class' AUX (dmtfRealizesAuxClass $ dmtfProductPhysicalElementsAuxClass $ dmtfFRUPhysicalElementsAuxClass $ dmtfDoorAccessToPhysicalElementAuxClass $ dmtfPhysicalElementLocationAuxClass $ dmtfElementCapacityAuxClass $ dmtfParticipatesInSetAuxClass $ dmtfContainerAuxClass $ dmtfElementsLinkedAuxClass) ) ( <oid-oc6> NAME 'dmtfLogicalElementContentRule' DESC 'shows what auxiliary classes may go with the dmtfLogicalElement class' AUX (dmtfLogicalIdentityAuxClass) ) ( <oid-oc8> NAME 'dmtfConfigurationContentRule' DESC 'shows what auxiliary classes may go with the dmtfConfiguration class' AUX (dmtfConfigurationComponentAuxClass $ dmtfElementConfigurationAuxClass $ dmtfCollectionConfigurationAuxClass $ dmtfSettingContextAuxClass $ dmtfDependencyContextAuxClass) ) ( <oid-oc12> NAME 'dmtfSettingContentRule' DESC 'shows what auxiliary classes may go with the dmtfSetting class' AUX (dmtfElementSettingAuxClass $ dmtfDefaultSettingAuxClass $ dmtfSettingContextAuxClass $ dmtfCollectionSettingAuxClass) ) ( <oid-oc17> NAME 'dmtfSystemContentRule' DESC 'shows what auxiliary classes may go with the dmtfSystem class' AUX (dmtfSystemComponentAuxClass) ) Expires 3/31/99 [Page 36]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 ( <oid-oc18> NAME 'dmtfComputerSystemContentRule' DESC 'shows what auxiliary classes may go with the dmtfComputerSystem class' AUX (dmtfComputerSystemResourceAuxClass $ dmtfComponentCSAuxClass $ dmtfComponentCSAuxClass $ dmtfSystemPartitionAuxClass $ dmtfHostingCSAuxClass $ dmtfParticipatingCSAuxClass $ dmtfRunningOSAuxClass $ dmtfRoutersInBGPClusterAuxClass $ dmtfRoutersInASAuxClass $ dmtfInBGPPeerGroupAuxClass) ) ( <oid-oc19> NAME 'dmtfLogicalDeviceContentRule' DESC 'shows what auxiliary classes may go with the dmtfLogicalDevice class' AUX (dmtfRealizesAuxClass $ dmtfDeviceConnectionAuxClass $ dmtfDeviceConnectionAuxClass $ dmtfAllocatedResourceAuxClass $ dmtfDeviceServiceImplementationAuxClass $ dmtfDeviceSAPImplementationAuxClass $ dmtfDeviceSoftwareAuxClass $ dmtfPortOnDeviceAuxClass $ dmtfAssociatedSensorAuxClass $ dmtfAssociatedCoolingAuxClass $ dmtfSuppliesPowerAuxClass $ dmtfAssociatedBatteryAuxClass $ dmtfControlledByAuxClass $ dmtfAssociatedAlarmAuxClass $ dmtfDoorAccessToDeviceAuxClass $ dmtfDeviceIdentityAuxClass) ) ( <oid-oc20> NAME 'dmtfServiceContentRule' DESC 'shows what auxiliary classes may go with the dmtfService class' AUX (dmtfServiceAccessBySAPAuxClass $ dmtfProvidesServiceToElementAuxClass $ dmtfServiceServiceDependencyAuxClass $ dmtfServiceServiceDependencyAuxClass $ dmtfServiceSAPDependencyAuxClass $ dmtfServiceComponentAuxClass $ dmtfServiceComponentAuxClass $ dmtfDeviceServiceImplementationAuxClass $ dmtfSoftwareFeatureServiceImplementationAuxClass $ dmtfServiceComponentAuxClass $ dmtfServiceComponentAuxClass) ) ( <oid-oc21> NAME 'dmtfServiceAccessPointContentRule' DESC 'shows what auxiliary classes may go with the dmtfServiceAccessPoint class' AUX (dmtfServiceAccessBySAPAuxClass $ dmtfServiceSAPDependencyAuxClass $ Expires 3/31/99 [Page 37]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 dmtfSAPSAPDependencyAuxClass $ dmtfSAPSAPDependencyAuxClass $ dmtfDeviceSAPImplementationAuxClass $ dmtfSoftwareFeatureSAPImplementationAuxClass $ dmtfBindsToAuxClass) ) ( <oid-oc33> NAME 'dmtfProductContentRule' DESC 'shows what auxiliary classes may go with the dmtfProduct class' AUX (dmtfProductParentChildAuxClass $ dmtfProductParentChildAuxClass $ dmtfCompatibleProductAuxClass $ dmtfCompatibleProductAuxClass $ dmtfProductProductDependencyAuxClass $ dmtfProductProductDependencyAuxClass $ dmtfProductSupportAuxClass $ dmtfProductFRUAuxClass $ dmtfProductPhysicalElementsAuxClass $ dmtfFRUIncludesProductAuxClass) ) ( <oid-oc37> NAME 'dmtfSupportAccessContentRule' DESC 'shows what auxiliary classes may go with the dmtfSupportAccess class' AUX (dmtfProductSupportAuxClass) ) ( <oid-oc39> NAME 'dmtfFRUContentRule' DESC 'shows what auxiliary classes may go with the dmtfFRU class' AUX (dmtfProductFRUAuxClass $ dmtfFRUPhysicalElementsAuxClass $ dmtfFRUIncludesProductAuxClass) ) ( <oid-oc44> NAME 'dmtfStatisticalInformationContentRule' DESC 'shows what auxiliary classes may go with the dmtfStatisticalInformation class' AUX (dmtfStatisticsAuxClass $ dmtfRelatedStatisticsAuxClass $ dmtfRelatedStatisticsAuxClass) ) 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. Expires 3/31/99 [Page 38]
INTERNET DRAFT LDAP Schema for the DMTF Core CIM Model September 1999 [2] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Synatx 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 Core Model, v2.2". [5] Ryan Moats, Gerald Maziarski, John Strassner, "LDAP Schema for the DMTF Application CIM Model", October 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 Physical 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 3/31/99 [Page 39]