Internet-Draft Ryan Moats draft-moats-dmtf-application-ldap-00.txt Gerald Maziarski Expires in six months AT&T John Strassner cisco Systems October 1999 LDAP Schema for the DMTF Application CIM Model Filename: draft-moats-dmtf-application-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 Application model version 2.2 [4]. 1. Introduction This draft presents a LDAPv3 [1,2] schema for the DMTF CIM Application 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. Differences between this schema and the source CIM model The only issue in mapping this model to LDAP is that there is an attribute definition collision between this model and the system model. The attribute codeSet is defined with different syntax in Expires 4/30/00 [Page 1]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 both models, so codeSet in this model has been renamed codeSetString. 3. Class Definitions For efficiency in the LDAP representation, associations are specified as a combination of auxiliary classes and DIT structure rules. Attribute definitions for each class are presented with the object class. Other definitions are also provided when necessary. This approach minimizes the number of DN pointers stored in the schema, but some pointer dereferencing is necessary. While not explicitly stated in the definitions below, we assume that all attributes with DN support the matching rule defined in [3]. Attribute names for DN pointers also follow the convention that a single pointer's name ends in "Ref", while an array of pointers' name ends in "Refs". Note: all OIDs are place holders, and OIDs in definitions have been replaced by names for clarity. 3.1 dmtfApplicationSystem This class represents an application or a software system that supports a particular business function and that can be managed as independent units. The dmtfSoftwareFeature class allows such a system to be decomposed into its functional pieces. The software features for a particular application or software system are located using dmtfApplicationSystemSoftwareFeatureAuxClass. ( <oid-oc231> NAME 'dmtfApplicationSystem' DESC 'represents an application or a software system that supports a particular business function and that can be managed as independent units.' SUP dmtfSystem ) 3.2 dmtfSoftwareElement This class decomposes a dmtfSoftwareFeature object into a set of individually manageable or deployable parts for a particular platform. A software element's underlying hardware architecture and operating system uniquely identifies its platform. As such, to understand the details of how the functionality of a particular software feature is provided on a particular platform, the dmtfSoftwareElement objects referenced by dmtfSoftwareFeatureSoftwareElementAuxClass are organized in disjoint sets based on the targetOperatingSystem property. A dmtfSoftwareElement object captures the management details of a part Expires 4/30/00 [Page 2]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 or component in one of four states characterized by the SoftwareElementState property. ( <oid-at552> NAME 'softwareElementState' DESC ' The SoftwareElementState is defined in this model to identify various states of a software elements life cycle. - A software element in the deployable state describes the details necessary to successful distribute it and the details (conditions and actions) required to create a software element in the installable state (i.e, the next state). - A software element in the installable state describes the details necessary to successfully install it and the details (conditions and actions required to create a software element in the executable state (i.e., the next state). - A software element in the executable state describes the details necessary to successfully start it and the details (conditions and actions required to create a software element in the running state (i.e., the next state). - A software element in the running state describes the details necessary to monitor and operate on a start element. May be used as an RDN. Allowed values are: "Deployable", "Installable", "Executable", "Running".' SYNTAX integer SINGLE-VALUE ) ( <oid-at553> NAME 'softwareElementID' DESC ' This is an identifier for this software element and is designed to be used with other keys to create a unique representation of this SoftwareElement. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at554> NAME 'targetOperatingSystem' DESC ' The Target Operating System property allows the provider to specify the operating system environment. The value of this property does not ensure binary executable. Two other pieces of information are needed. First, the version of the OS needs to be specified. using the OS Version Check. The second piece of information is the architecture the OS runs on. This information is capture with the ArchitectureCheck class. The combination of these constructs allows the provider to clearly identify the level of OS required for a particular software element. May be used as an RDN. Allowed values are: "Unknown", "Other", "MACOS", "ATTUNIX", "DGUX", "DECNT", "Digital Unix", "OpenVMS", "HPUX", "AIX", "MVS", "OS400", "OS/2", Expires 4/30/00 [Page 3]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 "JavaVM", "MSDOS", "WIN3x", "WIN95", "WIN98", "WINNT", "WINCE", "NCR3000", "NetWare", "OSF", "DC/OS", "Reliant UNIX", "SCO UnixWare", "SCO OpenServer", "Sequent", "IRIX", "Solaris", "SunOS", "U6000", "ASERIES", "TandemNSK", "TandemNT", "BS2000", "LINUX", "Lynx", "XENIX", "VM/ESA", "Interactive UNIX", "BSDUNIX", "FreeBSD", "NetBSD", "GNU Hurd", "OS9", "MACH Kernel", "Inferno", "QNX", "EPOC", "IxWorks", "VxWorks", "MiNT", "BeOS", "HP MPE", "NextStep", "PalmPilot", "Rhapsody".' SYNTAX integer SINGLE-VALUE ) ( <oid-at555> NAME 'otherTargetOS' DESC ' The otherTargetOS property records the manufacturer and operating system type for a software element when the targetOperatingSystem property has a value of 1 ("Other") For all other values of TargetOperatingSystem, the OtherTargetOS property is to be NULL.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at556> NAME 'buildNumber' DESC 'The internal identifier for this compilation of this software element.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at442> NAME 'codeSetString' DESC 'Array defining the character sets' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at557> NAME 'identificationCode' DESC ' The value of this property is the manufacturer's identifier for this software element. Often this will be a stock keeping unit (SKU) or a part number.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at558> NAME 'languageEdition' DESC 'The value of this property identifies the language edition of this software element. The language codes defined in ISO 639 should be used. Where the software element represents multi-lingual or international version of a product, the string multilingual should be used.' SYNTAX string{32} SINGLE-VALUE ) Expires 4/30/00 [Page 4]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 ( <oid-oc232> NAME 'dmtfSoftwareElement' DESC 'decomposes a dmtfSoftwareFeature object into a set of individually manageable or deployable parts for a particular platform.' SUP dmtfLogicalElement MUST (name $ version $ softwareElementState $ softwareElementID $ targetOperatingSystem $ otherTargetOS $ manufacturer $ buildNumber $ serialNumber $ codeSetString $ identificationCode $ languageEdition) ) 3.3 dmtfSoftwareFeature This class defines a particular function or capability of a product or application system. It captures the level of granularity that is significant to a consumer or user of a product rather than the units that reflect how the product is built or packaged, which is captured using the dmtfSoftwareElement class. When a software feature can exist on multiple platforms or operating systems (for example, a client component of a three tiered client/server applications might run on Solaris, Windows NT, and Windows 95), a software feature is a collection of all the software elements for these different platforms. Here, the users of the model must be aware of this since typically they will be interested in a sub-collection of the software elements required for a particular platform. Software Features are always defined in the context of a dmtfProduct class using DIT structure rules since features are delivered through products. Optionally, software features from one or more products can be organized into application systems using the dmtfApplicationSystemSoftwareFeatureAuxClass object. it reuses identifyingNumber, vendor, version, and name and defines productName. ( <oid-at559> NAME 'productName' DESC 'Commonly used Product name. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-oc233> NAME 'dmtfSoftwareFeature' DESC 'defines a particular function or capability of a product or application system.' SUP dmtfLogicalElement MUST (identifyingNumber $ productName $ vendor $ version $ name) ) While a variety of attributes may be used as RDN, the following structural rules are recommended. ( 28 NAME 'dmtfSoftwareFeatureStructureRule1' Expires 4/30/00 [Page 5]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 FORM dmtfSoftwareFeatureNameForm1 SUP 30 31 ) ( <oid-nf28> NAME 'dmtfSoftwareFeatureNameForm1' OC dmtfSoftwareFeature MUST (name) ) ( 29 NAME 'dmtfSoftwareFeatureStructureRule2' FORM dmtfSoftwareFeatureNameForm2 SUP 30 31 ) ( <oid-nf29> NAME 'dmtfSoftwareFeatureNameForm2' OC dmtfSoftwareFeature MUST (identifyingNumber) ) ( 30 NAME 'dmtfProductStructureRule1' FORM dmtfProductNameForm1 ) ( <oid-nf30> NAME 'dmtfProductNameForm1' OC dmtfProduct MUST (name) ) ( 31 NAME 'dmtfProductStructureRule2' FORM dmtfProductNameForm2 ) ( <oid-nf31> NAME 'dmtfProductNameForm2' OC dmtfProduct MUST (identifyingNumber) ) 3.4 dmtfCheck A Check is a condition or characteristic that is expected to be true in an environment defined or scoped by an instance of a dmtfComputerSystem. They are associated with a particular software element and are organized into one of two groups using the Phase property. Conditions that are expected to be satisfied when a software element is in a particular environment are known as in-state conditions. Conditions that need to be satisfied to transition the current software element to its next state are known as next-state conditions. Expires 4/30/00 [Page 6]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 it reuses name, version, softwareElementState, softwareElementID, targetOperatingSystem, description, and caption. It also defines checkID, phase and checkMode. ( <oid-at560> NAME 'checkID' DESC 'An identifier used with other keys to uniquely identify the check. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at561> NAME 'checkMode' DESC 'The CheckMode property is used to show whether the condition is expected to exist or not exist in the environment. When the value is True, the condition is expected to exist (e.g., a file is expected to be on a system) so invoke() is expected to return True. When the value is False, the condition is not expect to exist (e.g., a file is not to be on a system) so invoke is expected to return false.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at562> NAME 'phase' DESC ' The Phase property shows whether the referenced check is an in-state check or a next-state check. Allowed values are: "In-State", "Next-State".' SYNTAX integer SINGLE-VALUE ) ( <oid-oc234> NAME 'dmtfCheck' DESC 'A Check is a condition or characteristic that is expected to be true in an environment defined or scoped by an instance of a dmtfComputerSystem.' SUP top ABSTRACT MUST (name $ version $ softwareElementState $ softwareElementID $ targetOperatingSystem $ checkID $ description $ caption $ checkMode) ) While various attributes of dmtfCheck may be used as RDNs, the following structural rules are recommended. ( 32 NAME 'dmtfCheckStructureRule1' FORM dmtfCheckNameForm1 SUP 34 35 ) ( <oid-nf32> NAME 'dmtfCheckNameForm1' Expires 4/30/00 [Page 7]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 OC dmtfCheck MUST (name) ) ( 33 NAME 'dmtfCheckStructureRule1' FORM dmtfCheckNameForm1 SUP 34 35 ) ( <oid-nf33> NAME 'dmtfCheckNameForm1' OC dmtfCheck MUST (checkID) ) ( 34 NAME 'dmtfSoftwareElementStructureRule1' FORM dmtfSoftwareElementNameForm1 ) ( <oid-nf34> NAME 'dmtfSoftwareElementNameForm1' OC dmtfSoftwareElement MUST (name) ) ( 35 NAME 'dmtfSoftwareElementStructureRule2' FORM dmtfSoftwareElementNameForm2 ) ( <oid-nf35> NAME 'dmtfSoftwareElementNameForm2' OC dmtfSoftwareElement MUST (softwareElementID) ) 3.5 dmtfDirectorySpecification A directory specification captures the major directory structure of a software element and organizes the files of a software element into manageable units that can be relocated on a computer system. it defines the attributes directoryType, directoryPath. ( <oid-at563> NAME 'directoryType' DESC 'The DirectoryType property characterizes the type of directory being described. Allowed values are: "Product base directory", "Product executable directory", "Product library directory", "Product configuration directory", "Product include directory", "Product working directory", "Product log directory", "Shared base directory", "Shared executable directory", "Shared library directory", "Shared Expires 4/30/00 [Page 8]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 include directory", "System base directory", "System executable directory", "System library directory", "System configuration directory", "System include directory", "System log directory", "Other".' SYNTAX integer SINGLE-VALUE ) ( <oid-at564> NAME 'directoryPath' DESC 'The DirectoryPath property is used to capture the name of a directory. The value supplied by an application provider is actually a default or recommended path name. The value can be changed for a particular environment.' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-oc235> NAME 'dmtfDirectorySpecification' DESC 'The dmtfDirectorySpecification class captures the major directory structure of a software element. it is used to organize the files of a software element into manageable units that can be relocated on a computer system.' SUP dmtfCheck MUST (directoryType $ directoryPath) ) 3.6 dmtfArchitectureCheck Architecture checks specify the hardware platform a software element can run on. Its attributes are compared with the corresponding processor attributes. As long as there is at least one processor that satisfies the details of the condition, the check is satisfied. ( <oid-at565> NAME 'architectureType' DESC 'The ArchitectureType property identifies a particular type of architecture or architecture family that is required to properly execute a particular software element. The intent is to capture the details about the machine instructions exploited by the executables of the software element.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc236> NAME 'dmtfArchitectureCheck' DESC 'specifies the hardware platform a software element can run on.' SUP dmtfCheck MUST (architectureType) ) Expires 4/30/00 [Page 9]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 3.7 dmtfMemoryCheck Memory checks specifiy the minimum amount of memory that a system must have available. When an operating system has more free physical memory than the value specified in MemorySize, the condition is satisfied. ( <oid-at566> NAME 'memorySize' DESC 'The amount of memory that needs to exist on a computer system for a software element to executing properly.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc237> NAME 'dmtfMemoryCheck' DESC 'specifies a condition for the minimum amount of memory that needs to be available on a system.' SUP dmtfCheck MUST (memorySize) ) 3.8 dmtfDiskSpaceCheck Disk space checks specify the minimum amount of disk space that a system must have available. When a file system have more available space than the value specified in availableDiskSpace, the condition is satisfied. ( <oid-at567> NAME 'availableDiskSpace' DESC 'Amount of disk space needed.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc238> NAME 'dmtfDiskSpaceCheck' DESC 'specifies the amount of disk space the needs to be available on the system.' SUP dmtfCheck MUST (availableDiskSpace) ) 3.9 dmtfSwapSpaceCheck Swap space checks specify the minimum amount of swap space that a system must have available. When a system have more swap space available that the value in swapSpaceSize, the condition is satisfied. ( <oid-at568> NAME 'swapSpaceSize' DESC 'specifies the minimum number of Kilo bytes of swap space Expires 4/30/00 [Page 10]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 that needs to be available on the target system.' SYNTAX integer SINGLE-VALUE ) ( <oid-oc239> NAME 'dmtfSwapSpaceCheck' DESC 'specifies the amount of swap space that needs to be available on the system.' SUP dmtfCheck MUST (swapSpaceSize) ) 3.10 dmtfOSVersionCheck This class specifies the versions of the OS that can support this software element. This check can be for a specific, minimum, maximum or a range of releases of an OS. To specify a specific version the minimum and maximum versions must be the same. To specify a minimum, the minimum version needs only be specified. To specify a maximum version, the maximum version needs only be specified. To specify a range both minimum and maximum version need to be specified. The targetOperatingSystem attributes of the owning SoftwareElement specifies the type of operating system. The details of this checks are compared with the corresponding details found in a dmtfOperatingSystem object referenced by dmtfInstalledOSAuxClass. As long as there is at least one dmtfOperatingSystem object that satisfies the details of the condition, the check is satisfied. Also, note the the oSType attribute property of the dmtfOperatingSystem class must match the type of the targetOperatingSystem property. ( <oid-at569> NAME 'minimumVersion' DESC 'Minimum version of required operating system. The value is encoded as <major>.<minor>.<revision> or <major>.<minor><letter revision>.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at570> NAME 'maximumVersion' DESC 'Maximum version of required operating system. The value is encoded as <major>.<minor>.<revision> or <major>.<minor><letter revision>.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-oc240> NAME 'dmtfOSVersionCheck' DESC 'specifies the versions of the OS that can support this software element.' SUP dmtfCheck MUST (minimumVersion $ maximumVersion) Expires 4/30/00 [Page 11]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 ) 3.11 dmtfSoftwareElementVersionCheck This class specifies a type of software element that must exist in the environment. This check can be for a specific, minimum, maximum or a range of versions. To specify a specific version the lower and upper versions must be the same. To specify a minimum the lower version needs only be specified. To specify a maximum version the upper version needs only be specified. To specify a range both upper and lower version need to be specified. The details of this checks are compared with the corresponding details found in a dmtfSoftwareElement object referenced by an InstalledSoftwareElement association for the dmtfComputerSystem object. As long as there is at least one dmtfSoftwareElement that satisfies the details of the condition, the check is satisfied. ( <oid-at571> NAME 'softwareElementName' DESC 'The name of the software element being checked.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at572> NAME 'lowerSoftwareElementVersion' DESC 'The minimum version of a software elements being checked.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at573> NAME 'upperSoftwareElementVersion' DESC 'The maximum version of a software elements being checked.' SYNTAX string{64} SINGLE-VALUE ) ( <oid-at574> NAME 'softwareElementStateDesired' DESC 'The state of the software element being checked. Allowed values are: "Deployable", "Installable", "Executable", "Running".' SYNTAX integer SINGLE-VALUE ) ( <oid-at575> NAME 'targetOperatingSystemDesired' DESC 'The target operating system of the software element being checked. Allowed values are: "Unknown", "Other", "MACOS", "ATTUNIX", "DGUX", "DECNT", "Digital Unix", "OpenVMS", "HPUX", "AIX", "MVS", "OS400", "OS/2", "JavaVM", "MSDOS", "WIN3x", "WIN95", "WIN98", "WINNT", "WINCE", "NCR3000", "NetWare", "OSF", "DC/OS", "Reliant UNIX", "SCO UnixWare", "SCO OpenServer", "Sequent", "IRIX", "Solaris", "SunOS", "U6000", "ASERIES", "TandemNSK", "TandemNT", "BS2000", Expires 4/30/00 [Page 12]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 "LINUX", "Lynx", "XENIX", "VM/ESA", "Interactive UNIX", "BSDUNIX", "FreeBSD", "NetBSD", "GNU Hurd", "OS9", "MACH Kernel", "Inferno", "QNX", "EPOC", "IxWorks", "VxWorks", "MiNT", "BeOS", "HP MPE", "NextStep", "PalmPilot", "Rhapsody".' SYNTAX integer SINGLE-VALUE ) ( <oid-oc241> NAME 'dmtfSoftwareElementVersionCheck' DESC 'specifies a type of software element that must exist in the environment.' SUP dmtfCheck MUST (softwareElementName $ lowerSoftwareElementVersion $ upperSoftwareElementVersion $ softwareElementStateDesired $ targetOperatingSystemDesired) ) 3.12 dmtfFileSpecification A dmtfFileSpecification object identifies a file that is either to be on or off the system. DmtfDirectorySpecificationFileAuxClass identifies the directory the file is to be located in. ( <oid-at576> NAME 'fileName' DESC 'Either the name of the file or the name of the file with a directory prefix.' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-at577> NAME 'createTimeStamp' DESC 'The creation date and time of the file.' SYNTAX generalizedTime SINGLE-VALUE ) ( <oid-at578> NAME 'fileSize' DESC 'Size of the File in bytes..' SYNTAX integer SINGLE-VALUE ) ( <oid-at579> NAME 'checkSum' DESC 'The File Checksum property is a checksum calculated as the 16-bit sum of the first 32 bytes of the file.' SYNTAX integer SINGLE-VALUE ) ( <oid-at580> NAME 'cRC1' DESC 'The File CRC 1 property is the CRC value calculated using the middle 512K bytes.' Expires 4/30/00 [Page 13]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 SYNTAX integer SINGLE-VALUE ) ( <oid-at581> NAME 'cRC2' DESC 'The File CRC 2 is the CRC value for the middle 512K bytes with a offset modulo 3 to the start of the file of zero.' SYNTAX integer SINGLE-VALUE ) ( <oid-at582> NAME 'mD5Checksum' DESC 'The MD5 checksum of the file.' SYNTAX string SINGLE-VALUE ) ( <oid-oc242> NAME 'dmtfFileSpecification' DESC 'identifies a file that is either to be on or off the system.' SUP dmtfCheck MUST (fileName $ createTimeStamp $ fileSize $ checkSum $ cRC1 $ cRC2 $ mD5Checksum) ) 3.13 dmtfVersionCompatibilityCheck This class specifies whether it is permissible to create the next state of a software element. It defines the attributes allowDownVersion, allowMultipleVersions, and reinstall. ( <oid-at583> NAME 'allowDownVersion' DESC 'The AllowDownVersion property shows that this software element can transition to its next state even if a higher or latter version of the software element already exists in the environment.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at584> NAME 'allowMultipleVersions' DESC 'The AllowMultipleVersions option controls the ability to configure multiple versions of a product on a system.' SYNTAX boolean SINGLE-VALUE ) ( <oid-at585> NAME 'reinstall' DESC 'The Reinstall property shows that this software element can transition to its next state even if a software element of the same version already exists in the environment.' SYNTAX boolean SINGLE-VALUE ) Expires 4/30/00 [Page 14]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 ( <oid-oc243> NAME 'dmtfVersionCompatibilityCheck' DESC 'specifies whether it is permissible to create the next state of a software element.' SUP dmtfCheck MUST (allowDownVersion $ allowMultipleVersions $ reinstall) ) 3.14 dmtfAction This abstract class represents an operation that is part of a process to either create a SoftwareElement in its next state or to eliminate the SoftwareElement in the current state. It uses the attributes name, version, softwareElementState, softwareElementID, targetOperatingSystem, actionID, direction, caption, and description. ( <oid-at586> NAME 'actionID' DESC 'The ActionID property is a unique identifier assigned to a particular action for a software element. May be used as an RDN.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at587> NAME 'direction' DESC 'The Direction property is used to show whether a particular action object is part of a sequence of actions to transition the currentsoftware element to its next state, such as Install or to remove the current software element, such as Uninstall. Allowed values are: "Install", "Uninstall".' SYNTAX integer SINGLE-VALUE ) ( <oid-oc244> NAME 'dmtfAction' DESC 'an operation that is part of a process to either create a SoftwareElement in its next state or to eliminate the SoftwareElement in the current state.' SUP top ABSTRACT MUST (name $ version $ softwareElementState $ softwareElementID $ targetOperatingSystem $ actionID $ direction $ caption $ description) ) Although a variety of attributes may be used as RDNs, the following structural rules are recommended: ( 36 NAME 'dmtfActionStructureRule1' FORM dmtfActionNameForm1 SUP 34 35 ) Expires 4/30/00 [Page 15]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 ( <oid-nf36> NAME 'dmtfActionNameForm1' OC dmtfAction MUST (name) ) ( 37 NAME 'dmtfActionStructureRule2' FORM dmtfActionNameForm1 SUP 34 35 ) ( <oid-nf37> NAME 'dmtfActionNameForm2' OC dmtfAction MUST (actionID) ) 3.15 dmtfDirectoryAction This abstract class manages directories to be managed. Creation of directories is handled by dmtfCreateDirectoryAction and removal is handled by dmtfRemoveDirectoryAction. ( <oid-at588> NAME 'directoryName' DESC 'The name of the directory.' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-oc245> NAME 'dmtfDirectoryAction' DESC 'used for directories to be managed.' SUP dmtfAction ABSTRACT MUST (directoryName) ) 3.16 dmtfCreateDirectoryAction This class creates empty directories for dmtfSoftwareElement objects to be installed locally. ( <oid-oc246> NAME 'dmtfCreateDirectoryAction' DESC 'creates empty directories for SoftwareElements to be installed locally.' SUP dmtfDirectoryAction ) 3.17 dmtfRemoveDirectoryAction This class removes directories for dmtfSoftwareElement objects. ( <oid-at589> NAME 'mustBeEmpty' Expires 4/30/00 [Page 16]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 DESC 'shows whether the directory must be empty (TRUE) to be removed' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc247> NAME 'dmtfRemoveDirectoryAction' DESC 'removes directories for SoftwareElements.' SUP dmtfDirectoryAction MUST (mustBeEmpty) ) 3.18 dmtfFileAction This abstract class allows an implementor to locate files that already exist on the users machine, and move or copy those files to a new location. ( <oid-oc248> NAME 'dmtfFileAction' DESC 'allows an implementor to locate files that already exist on the users machine, and move or copy those files to a new location.' SUP dmtfAction ABSTRACT ) 3.19 dmtfCopyFileAction This class specifies files that exist on a computer system, and to move or copy those files to a new location. ( <oid-at590> NAME 'source' DESC 'source location' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-at591> NAME 'destination' DESC 'destination location' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-at592> NAME 'deleteAfterCopy' DESC 'boolean indicating if the file should be moved (true)' SYNTAX boolean SINGLE-VALUE ) ( <oid-oc249> NAME 'dmtfCopyFileAction' DESC 'specifies files that exist on a computer system, and to move or copy those files to a new location.' SUP dmtfFileAction Expires 4/30/00 [Page 17]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 MUST (source $ destination $ deleteAfterCopy) ) 3.20 dmtfRemoveFileAction This class uninstalls files, specified in the file attribute. ( <oid-at593> NAME 'file' DESC 'file to be removed' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-oc250> NAME 'dmtfRemoveFileAction' DESC 'uninstalls files' SUP dmtfFileAction MUST (file) ) 3.21 dmtfRebootAction This class causes a reboot of the system where the software element is installed. ( <oid-oc251> NAME 'dmtfRebootAction' DESC 'Causes a reboot of the system where the SoftwareElement is installed.' SUP dmtfAction ) 3.22 dmtfExecuteProgram This class causes files to be executed on the system where the dmtfSoftwareElement object is installed. It uses the attributes programPath and commandLine. ( <oid-at594> NAME 'programPath' DESC 'Path to the executable' SYNTAX string{1024} SINGLE-VALUE ) ( <oid-at595> NAME 'commandLine' DESC 'A string that is invocable on a system command line.' SYNTAX string SINGLE-VALUE ) ( <oid-oc252> NAME 'dmtfExecuteProgram' DESC 'causes files to be executed on the system where the SoftwareElement is installed.' Expires 4/30/00 [Page 18]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 SUP dmtfAction MUST (programPath $ commandLine) ) 3.23 dmtfSettingCheck This class specifies information needed to check a particular setting file for a specific entry that contains a value that is equal to, or contains, the value specified. All compares are case insensitive. ( <oid-at596> NAME 'sectionKey' DESC 'Key of section containing the settings to be checked.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at597> NAME 'entryName' DESC 'Name of the Entry to be checked.' SYNTAX string{256} SINGLE-VALUE ) ( <oid-at598> NAME 'entryValue' DESC 'Value to be checked that is associated with the named entry.' SYNTAX string SINGLE-VALUE ) ( <oid-at599> NAME 'checkType' DESC 'This specifies the way the setting value should be compared. Allowed values are: "Matches", "Contains".' SYNTAX integer SINGLE-VALUE ) ( <oid-oc253> NAME 'dmtfSettingCheck' DESC 'specifies information needed to check a particular setting file for a specific entry that contains a value that is equal to, or contains, the value specified.' SUP dmtfCheck MUST (sectionKey $ entryName $ entryValue $ checkType $ fileName) ) 3.24 dmtfModifySettingAction This class specifies the information to be used to change a particular setting file for a specific entry with a specific value. All additions are case sensitive while removes are case insensitive. ( <oid-at600> NAME 'actionType' DESC 'Type of action to be performed on the specified setting Expires 4/30/00 [Page 19]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 entry. Create - Creates the specified entry. Delete - Deletes the specified entry. Append - Append to the end of the specified entry. Remove - Remove the value from the specified entry. Allowed values are: "Create", "Delete", "Append", "Remove".' SYNTAX integer SINGLE-VALUE ) ( <oid-oc254> NAME 'dmtfModifySettingAction' DESC 'specifies the information to be used to change a particular setting file for a specific entry with a specif1ic value.' SUP dmtfAction MUST (sectionKey $ entryName $ entryValue $ fileName $ actionType) ) 3.25 dmtfDirectorySpecificationFileAuxClass This class identifies the directory that contains the file being specified by referencing the dmtfDirectorySpecification class. ( <oid-at601> NAME 'dmtfDirectorySpecificationRef' DESC 'The directory specification' SYNTAX DN SINGLE-VALUE ) ( <oid-at602> NAME 'dmtfFileSpecificationRefs' DESC 'File Specifications' SYNTAX DN ) ( <oid-oc255> NAME 'dmtfDirectorySpecificationFileAuxClass' DESC 'identifies the directorythat contains the file being specified by referencing the dmtfDirectorySpecification class.' SUP top AUXILIARY MUST (dmtfDirectorySpecificationRef $ dmtfFileSpecificationRefs) ) 3.26 dmtfActionSequenceAuxClass dmtfActionSequenceAuxClass defines a series of operations that either transitions the software element, referenced by dmtfSoftwareElementActionsAuxClass, to its next state or removes the software element from its current environment. The action classes participating in this association must have the same value for the direction property since they are either part of a sequence to transition a software element into its next state or to uninstall a Expires 4/30/00 [Page 20]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 software element. The next-state actions and uninstall actions associated with a particular software element must be a continuos sequence. Since the action sequence is an association the loops on the action class with roles for the 'prior' action and 'next' action in a sequence, the need for a continous sequence implies: (1)Within the set of next-state or uninstall actions, there is one and only one action that does not have an instance of the ActionSequence association referencing it in the 'next' role. This is the first action in the sequence. (2) Within the set of next-state or uninstall actions, there is one and only one action that does not have an instance of the ActionSequence association referencing it in the 'prior' role. This is the last action in the sequence. (3) All other actions within the set of next-state and uninstall actions must participate in two instances of the ActionSequence association, one in a prior role and one in the next role. ( <oid-at603> NAME 'nextActionRef' DESC 'next action' SYNTAX DN SINGLE-VALUE ) ( <oid-at604> NAME 'priorActionRef' DESC 'next action' SYNTAX DN SINGLE-VALUE ) ( <oid-oc256> NAME 'dmtfActionSequenceAuxClass' DESC 'used to define a series of operations that either transitions the software element, referenced by the dmtfSoftwareElementActions association, to its next state or removes the software element from its current environment.' SUP top AUXILIARY MUST (nextActionRef $ priorActionRef) ) 3.27 dmtfSoftwareFeatureSoftwareElementsAuxClass This auxiliary class identifies the software elements that make up a particular software feature. In it, groupComponentRefs point to dmtfSoftwareFeature objects and partComponentRefs point to dmtfSoftwareElement objects. ( <oid-oc257> NAME 'dmtfSoftwareFeatureSoftwareElementsAuxClass' DESC 'identifies the software elements that make up a particular software feature.' SUP dmtfComponentAuxClass AUXILIARY ) Expires 4/30/00 [Page 21]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 3.28 dmtfToDirectorySpecificationAuxClass This auxiliary class identifies the target directory for the file action and assumes that the target directory already existed. This association cannot exist with a dmtfToDirectoryActionAuxClass since a file action can only involve a single target directory. ( <oid-at605> NAME 'dmtfDirectorySpecificationRef' DESC 'directory specification indicating the destination' SYNTAX DN SINGLE-VALUE ) ( <oid-at606> NAME 'dmtfCopyFileActionRefs' DESC 'List of copy file actions' SYNTAX DN ) ( <oid-oc258> NAME 'dmtfToDirectorySpecificationAuxClass' DESC 'identifies the target directory for the file action.' SUP top AUXILIARY MUST (dmtfDirectorySpecificationRef $ dmtfCopyFileActionRefs) ) 3.29 dmtfFromDirectorySpecificationAuxClass This auxiliary class identifies the source directory for the file action and assumed that the source directory already existed. This association cannot exist with a dmtfFromDirectoryActionAuxClass since a file action can only involve single source directory. ( <oid-at607> NAME 'dmtfFileActionRefs' DESC 'a list of file actions' SYNTAX DN ) ( <oid-oc259> NAME 'dmtfFromDirectorySpecificationAuxClass' DESC 'identifies the source directory for the file action.' SUP top AUXILIARY MUST (dmtfDirectorySpecificationRef $ dmtfFileActionRefs) ) 3.30 dmtfToDirectoryActionAuxClass This auxiliary class identifies the target directory for the file action and assumes that a previos action creates the target directory This association cannot exist with a dmtfToDirectorySpecificationAuxClass since a file action can only involve a single target directory. Expires 4/30/00 [Page 22]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 ( <oid-at608> NAME 'dmtfDirectoryActionRef' DESC 'directory action reference' SYNTAX DN SINGLE-VALUE ) ( <oid-oc260> NAME 'dmtfToDirectoryActionAuxClass' DESC 'identifies the target directory for the file action.' SUP top AUXILIARY MUST (dmtfDirectoryActionRef $ dmtfCopyFileActionRefs) ) 3.31 dmtfFromDirectoryActionAuxClass This auxiliary class identifies the source directory for the file action and assumes that a previous action creates the source directory. It cannot exist with a dmtfFromDirectorySpecificationAuxClass since a file action can only involve a single source directory. ( <oid-oc261> NAME 'dmtfFromDirectoryActionAuxClass' DESC 'identifies the source directory for the file action.' SUP top AUXILIARY MUST (dmtfDirectoryActionRef $ dmtfFileActionRefs) ) 3.32 dmtfSoftwareFeatureServiceImplementationAuxClass This auxiliary class relates a service and how it is implemented in software and has a many-to-many cardinality. A service may be provided by more than one software feature, operating in conjunction and, any software feature may provide more than one service. If different implementations of a service exist, each of these implementations are individual instantiations of the dmtfService object. These individual instantiations would then have associations to the unique implementations. ( <oid-oc262> NAME 'dmtfSoftwareFeatureServiceImplementationAuxClass' DESC 'relation between a Service and how it is implemented in software.' SUP dmtfDependencyAuxClass AUXILIARY ) 3.33 dmtfSoftwareFeatureSAPImplementationAuxClass This auxiliary class represents the relationship between a eervice access point and how it is implemented in software. The cardinality of this association is many-to-many. A SAP may be provided by more than one SoftwareFeature, operating in conjunction. And, any Expires 4/30/00 [Page 23]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 SoftwareFeature may provide more than one ServiceAccessPoint. a When many SoftwareFeatures are associated with single SAP, it is assumed that these elements operate in conjunction to provide the AccessPoint. If different implementations of a SAP exist, each of these implementations would result in individual instantiations of the ServiceAccessPoint object. These individual instantiations would then have associations to the unique implementations. ( <oid-oc263> NAME 'dmtfSoftwareFeatureSAPImplementationAuxClass' DESC 'relationship between a ServiceAccessPoint and how it is implemented in software.' SUP dmtfDependency AUXILIARY ) 3.34 dmtfApplicationSystemSoftwareFeatureAuxClass This auxiliary class identifies the software features, which may be part of different products, that make up a particular application system. ( <oid-oc264> NAME 'dmtfApplicationSystemSoftwareFeatureAuxClass' DESC 'identifies the software features that make up a particular application system.' SUP dmtfSystemComponentAuxClass AUXILIARY ) 3.35 dmtfInstalledSoftwareElementAuxClass This auxiliary class allows one to identify the computer system a particular software element is installed on. ( <oid-at609> name 'dmtfSoftwareElementRefs' DESC 'references software elements that are installed' SYNTAX DN ) ( <oid-at610> name 'dmtfComputerSystemRef' DESC 'references the computer system hosting a particular software element' SYNTAX DN SINGLE-VALUE ) ( <oid-oc265> name 'dmtfInstalledSoftwareElementAuxClass' DESC 'identifies the Computer System a particular Software element is installed on.' SUP top AUXILIARY MUST (dmtfSoftwareElementRefs $ dmtfComputerSystemRef) Expires 4/30/00 [Page 24]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 4. 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 schemata [5, 6, 7, 8, 9] ( <oid-oc231> NAME 'dmtfApplicationSystemContentRule' DESC 'shows what auxiliary classes may go with the dmtfApplicationSystem class' AUX (dmtfApplicationSystemSoftwareFeatureAuxClass) ) ( <oid-oc232> NAME 'dmtfSoftwareElementContentRule' DESC 'shows what auxiliary classes may go with the dmtfSoftwareElement class' AUX (dmtfDeviceSoftwareAuxClass $ dmtfSoftwareFeatureSoftwareElementsAuxClass) ) ( <oid-oc233> NAME 'dmtfSoftwareFeatureContentRule' DESC 'shows what auxiliary classes may go with the dmtfSoftwareFeature class' AUX (dmtfOperatingSystemSoftwareFeatureAuxClass $ dmtfSoftwareFeatureSoftwareElementsAuxClass $ dmtfSoftwareFeatureServiceImplementationAuxClass $ dmtfSoftwareFeatureSAPImplementationAuxClass $ dmtfApplicationSystemSoftwareFeatureAuxClass) ) ( <oid-oc235> NAME 'dmtfDirectorySpecificationContentRule' DESC 'shows what auxiliary classes may go with the dmtfDirectorySpecification class' AUX (dmtfDirectorySpecificationFileAuxClass $ dmtfToDirectorySpecificationAuxClass $ dmtfFromDirectorySpecificationAuxClass) ) ( <oid-oc242> NAME 'dmtfFileSpecificationContentRule' DESC 'shows what auxiliary classes may go with the dmtfFileSpecification class' AUX (dmtfDirectorySpecificationFileAuxClass) ) ( <oid-oc244> NAME 'dmtfActionContentRule' DESC 'shows what auxiliary classes may go with the dmtfAction class' AUX (dmtfActionSequenceAuxClass) ) Expires 4/30/00 [Page 25]
INTERNET DRAFTLDAP Schema for the DMTF Application CIM Model October 1999 ( <oid-oc245> NAME 'dmtfDirectoryActionContentRule' DESC 'shows what auxiliary classes may go with the dmtfDirectoryAction class' AUX (dmtfToDirectoryActionAuxClass $ dmtfFromDirectoryActionAuxClass) ) ( <oid-oc248> NAME 'dmtfFileActionContentRule' DESC 'shows what auxiliary classes may go with the dmtfFileAction class' AUX (dmtfFromDirectorySpecificationAuxClass $ dmtfFromDirectoryActionAuxClass) ) ( <oid-oc249> NAME 'dmtfCopyFileActionContentRule' DESC 'shows what auxiliary classes may go with the dmtfCopyFileAction class' AUX (dmtfToDirectorySpecificationAuxClass $ dmtfToDirectoryActionAuxClass) ) 5. 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 Application 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. Expires 4/30/00 [Page 26]
INTERNET DRAFTLDAP Schema for the DMTF Application 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. 6. 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 27]