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]