rfc3060.txt

最新的RFC

   The individual role names in a role combination must appear in
   alphabetical order (according to the collating sequence for UCS-2
   characters), to make the string matches work correctly.  The role
   names used in an environment are specified by the policy
   administrator.

5.3. Local Time and UTC Time in PolicyTimePeriodConditions

   An instance of PolicyTimePeriodCondition has up to five properties
   that represent times:  TimePeriod, MonthOfYearMask, DayOfMonthMask,
   DayOfWeekMask, and TimeOfDayMask.  All of the time-related properties
   in an instance of PolicyTimePeriodCondition represent one of two
   types of times:  local time at the place where a policy rule is
   applied, or UTC time.  The property LocalOrUtcTime indicates which
   time representation applies to an instance of
   PolicyTimePeriodCondition.

   Since the PCIM provides only for local time and UTC time, a Policy
   Management Tool that provides for other time representations (for
   example, a fixed time at a particular location) will need to map from
   these other representations to either local time or UTC time.  An
   example will illustrate the nature of this mapping.

   Suppose a policy rule is tied to the hours of operation for a Help
   Desk:  0800 to 2000 Monday through Friday [US] Eastern Time.  In
   order to express these times in PolicyTimePeriodCondition, a
   management tool must convert them to UTC times.  (They are not local
   times, because they refer to a single time interval worldwide, not to
   intervals tied to the local clocks at the locations where the



Moore, et al.               Standards Track                    [Page 21]

RFC 3060             Policy Core Information Model         February 2001


   PolicyRule is being applied.)  As reference [10] points out, mapping
   from [US] Eastern Time to UTC time is not simply a matter of applying
   an offset:  the offset between [US] Eastern Time and UTC time
   switches between -0500 and -0400 depending on whether Daylight
   Savings Time is in effect in the US.

   Suppose the policy administrator's goal is to have a policy rule be
   valid from 0800 until 1200 [US] Eastern Time on every Monday, within
   the overall time period from the beginning of 2000 until the end of
   2001.  The Policy Management Tool could either be configured with the
   definition of what [US] Eastern Time means, or it could be configured
   with knowledge of where to go to get this information.  Reference
   [10] contains further discussion of time zone definitions and where
   they might reside.

   Armed with knowledge about [US] Eastern Time, the Policy Management
   Tool would create however many instances of PolicyTimePeriodCondition
   it needed to represent the desired intervals.  Note that while there
   is an increased number of PolicyTimePeriodCondition instances, there
   is still just one PolicyRule, which is tied to all the
   PolicyTimePeriodCondition instances via the aggregation
   PolicyRuleValidityPeriod.  Here are the first two of these instances:

         1. TimePeriod:  20000101T050000/20000402T070000
            DayOfWeekMask:  { Monday }
            TimeOfDayMask:  T130000/T170000
            LocalOrUtcTime:  UTC

         2. TimePeriod:  20000402T070000/20001029T070000
            DayOfWeekMask:  { Monday }
            TimeOfDayMask:  T120000/T160000
            LocalOrUtcTime:  UTC

   There would be three more similar instances, for winter 2000-2001,
   summer 2001, and winter 2001 up through December 31.

   Had the example been chosen differently, there could have been even
   more instances of PolicyTimePeriodCondition.  If, for example, the

   time interval had been from 0800 - 2200 [US] Eastern Time on Mondays,
   instance 1 above would have split into two instances:  one with a UTC
   time interval of T130000/T240000 on Mondays, and another with a UTC
   time interval of T000000/T030000 on Tuesdays.  So the end result
   would have been ten instances of PolicyTimePeriodCondition, not five.

   By restricting PolicyTimePeriodCondition to local time and UTC time,
   the PCIM places the difficult and expensive task of mapping from
   "human" time representations to machine-friendly ones in the Policy



Moore, et al.               Standards Track                    [Page 22]

RFC 3060             Policy Core Information Model         February 2001


   Management Tool.  Another approach would have been to place in
   PolicyTimePeriodCondition a means of representing a named time zone,
   such as [US] Eastern Time.  This, however, would have passed the
   difficult mapping responsibility down to the PDPs and PEPs.  It is
   better to have a mapping such as the one described above done once in
   a Policy Management Tool, rather than having it done over and over in
   each of the PDPs (and possibly PEPs) that need to apply a PolicyRule.

5.4. CIM Data Types

   Since PCIM extends the CIM Schema, a correspondence between data
   types used in both CIM and PCIM is needed.  The following CIM data
   types are used in the class definitions that follow in Sections 6 and
   7:

   o uint8               unsigned 8-bit integer

   o uint16              unsigned 16-bit integer

   o boolean             Boolean

   o string              UCS-2 string.

   Strings in CIM are stored as UCS-2 characters, where each character
   is encoded in two octets.  Thus string values may need to be
   converted when moving between a CIM environment and one that uses a
   different string encoding.  For example, in an LDAP-accessible
   directory, attributes of type DirectoryString are stored in UTF-8
   format.  RFC 2279 [7] explains how to convert between these two
   formats.

   When it is applied to a CIM string, a MaxLen value refers to the
   maximum number of characters in the string, rather than to the
   maximum number of octets.

   In addition to the CIM data types listed above, the association
   classes in Section 7 use the following type:

   o <classname> ref     strongly typed reference.

   There is one obvious omission from this list of CIM data types:
   octet strings.  This is because CIM treats octet strings as a derived
   data type.  There are two forms of octet strings in CIM - an ordered
   uint8 array for single-valued strings, and a string array for multi-
   valued properties.  Both are described by adding an "OctetString"
   qualifier (meta-data) to the property.  This qualifier functions
   exactly like an SMIv2 (SNMP) Textual Convention, refining the syntax
   and semantics of the existing CIM data type.



Moore, et al.               Standards Track                    [Page 23]

RFC 3060             Policy Core Information Model         February 2001


   The first four numeric elements of both of the "OctetString"
   representations are a length field.  (The reason that the "numeric"
   adjective is added to the previous sentence is that the string
   property also includes '0' and 'x', as its first characters.)  In
   both cases, these 4 numeric elements (octets) are included in
   calculating the length.  For example, a single-valued octet string
   property having the value X'7C' would be represented by the uint8
   array, X'00 00 00 05 7C'.

   The strings representing the individual values of a multi-valued
   property qualified with the "OctetString" qualifier are constructed
   similarly:

   1. Take a value to be encoded as an octet string (we'll use X'7C' as
      above), and prepend to it a four-octet length.  The result is the
      same, X'00 00 00 05 7C'.

   2. Convert this to a character string by introducing '0' and 'x' at
      the front, and removing all white space.  Thus we have the 12-
      character string "0x000000057C".  This string is the value of one
      of the array elements in the CIM string array.  Since CIM uses the
      UCS-2 character set, it will require 24 octets to encode this 12-
      character string.

   Mappings of the PCIM to particular data models are not required to
   follow this CIM technique of representing multi-valued octet strings
   as length- prefixed character strings.  In an LDAP mapping, for
   example, it would be much more natural to simply use the Octet String
   syntax, and omit the prepended length octets.

5.5. Comparison between CIM and LDAP Class Specifications

   There are a number of differences between CIM and LDAP class
   specifications.  The ones that are relevant to the abbreviated class
   specifications in this document are listed below.  These items are
   included here to help introduce the IETF community, which is already
   familiar with LDAP, to CIM modeling, and by extension, to information
   modeling in general.

   o  Instead of LDAP's three class types (abstract, auxiliary,
      structural), CIM has only two:  abstract and instantiable.  The
      type of a CIM class is indicated by the Boolean qualifier
      ABSTRACT.

   o  CIM uses the term "property" for what LDAP terms an "attribute".






Moore, et al.               Standards Track                    [Page 24]

RFC 3060             Policy Core Information Model         February 2001


   o  CIM uses the array notation "[ ]" to indicate that a property is
      multi-valued.  CIM defines three types of arrays: bags (contents
      are unordered, duplicates allowed), ordered bags (contents are
      ordered but duplicates are allowed) and indexed arrays (contents
      are ordered and no duplicates are allowed).

   o  CIM classes and properties are identified by name, not by OID.

   o  CIM classes use a different naming scheme for native
      implementations, than LDAP.  The CIM naming scheme is documented
      in Appendix A since it is not critical to understanding the
      information model, and only applies when communicating with a
      native CIM implementation.

   o  In LDAP, attribute definitions are global, and the same attribute
      may appear in multiple classes.  In CIM, a property is defined
      within the scope of a single class definition.  The property may
      be inherited into subclasses of the class in which it is defined,
      but otherwise it cannot appear in other classes.  One side effect
      of this difference is that CIM property names tend to be much
      shorter than LDAP attribute names, since they are implicitly
      scoped by the name of the class in which they are defined.

   There is also a notational convention that this document follows, to
   improve readability.  In CIM, all class and property names are
   prefixed with the characters "CIM_".  These prefixes have been
   omitted throughout this document, with one exception regarding
   naming, documented in Appendix A.

   For the complete definition of the CIM specification language, see
   reference [2].

6. Class Definitions

   The following sections contain the definitions of the PCIM classes.

6.1. The Abstract Class "Policy"

   The abstract class Policy collects several properties that may be
   included in instances of any of the Core Policy classes (or their
   subclasses).  For convenience, the two properties that Policy
   inherits from ManagedElement in the CIM schema are shown here as
   well.








Moore, et al.               Standards Track                    [Page 25]

RFC 3060             Policy Core Information Model         February 2001


   The class definition is as follows:

      NAME             Policy
      DESCRIPTION      An abstract class with four properties for
                       describing a policy-related instance.
      DERIVED FROM     ManagedElement
      ABSTRACT         TRUE
      PROPERTIES       CommonName (CN)
                       PolicyKeywords[ ]
                              // Caption (inherited)
                              // Description (inherited)

6.1.1. The Property "CommonName (CN)"

   The CN, or CommonName, property corresponds to the X.500 attribute
   commonName (cn).  In X.500 this property specifies one or more user-
   friendly names (typically only one name) by which an object is
   commonly known, names that conform to the naming conventions of the
   country or culture with which the object is associated.  In the CIM
   model, however, the CommonName property is single-valued.

      NAME             CN
      DESCRIPTION      A user-friendly name of a policy-related object