Subject: Preparing the Policy Core Information Model for Last Call

From: "ed hamlin" <[email-masked]>
Date: Thu, 23 Dec 1999 22:08:24 -0600

Policy Enthusiasts,

despite the "From" label, this is really me, John Strassner, at my in-laws.
My own computer is verklempt ;-)  Please do NOT respond to the sender of
this email (they won't know or care about IETF issues) but rather to either
myself, [email-masked], or to the policy mailing list
([email-masked]).

At any rate, Ed and I, with our ADs, have been discussing how to move the
Core Information Model into Last Call. This message is a summary of that
plan, as well as a call to action to consider carefully any last changes
that you would like to make, so that you can alert the co-athors before we
issue the next revision of this document.

The target date for release of the next draft of the Core Information Model
is no later than Friday, 14 January. We would like to move to Last Call as
soon as possible, so please do read the draft.

The Core Information Model has been very close to consensus for many months
now. We have, however, reached a point of diminishing returns and increased
controversy. Therefore, the authors, along with the WG chairs and the ADs,
have agreed to remove the remaining contentious portions of the Core
Information Model (with respect to its latest version that was submitted in
Washington) in order to get this document to a stable state where a Last
Call can be issued. This involves backing out some of the more recent
changes that were introduced in the latest version, such as ResourceManager.
However, other changes that were introduced in this version that were well
received, such as making Policy weak to System, will remain. The basic
approach is to root the Core Information Model in published, released work,
avoiding the use of dependencies on classes that are in a state of flux and
not already standardized (no matter how appealing their use might be). Thus,
what you see below are the steps necessary to remove all dependencies on
classes that are beyond the CIM 2.2 release. Here is the approach:

1. Remove CIM_ManagedElement. This involves:

    - reparenting the Policy class from
      CIM_ManagedElement to Top
    - reparent the CIM_System class to
      CIM_LogicalElement (a subclass of
      CIM_ManagedSystemElement)
    - replace the ConditionSubject relationship
      with either a relationship to
      CIM_ManagedSystemElement or remove it
    - replace the ConditionTarget relationship
      with either a relationship to
      CIM_ManagedSystemElement or remove it

2. Section 6.9, PolicyRepository

There are some minor errors in this section that need to be cleaned up.
Sepcifically, CreationClassName is an inherited key property, so it can not
be defined to be a key property in this class. In addition, the
PolicyRepositoryName property can not be defined as a key in this class.
These will be corrected in the next draft.

3. Remove CIM_Collection. This (proposed) class represents a fundamental
change to CIM, and is the subject of controversy in the DMTF. It should
therefore be pursued at a later date. This change involves:

    - remove CIM_ResourceManagerCollection
      (section 6.10). This also means that the
      following relationship should be nuked:
      - ResourceManagerCollectionPolicyGroup (7.16)
      - ResourceManagerCollectionPolicyRule (7.17)
      - MemberResourceManager (7.18)
      - ResourceManagerPolicyGroup (7.19)
      - ResourceManagerPolicyRule (7.20)
      - ResourceManagerManagedResource (7.21)

4. There is a phantom association class, MemberService, that is referenced
in Figure 3 and in Section 7.18, that is not defined. These references will
be removed.

5. PolicyInstance. This will be corrected, per the mail list discussion, to
include a structural policyInstance class that inherits from the abstract
Policy class, as well as two structural classes, policyConditionInstance and
policyActionInstance. It will also leave room for defining additional
policySomethingElseInstance classes from the ppolicyInstance class in the
future, if we need to.

6.  The question of using Atoms in the Core Model. There is still a lack of
consensus on this subject, and therefore we will restrict their use to the
QoS Model for the time being in order to gain implementation experience.

We believe that this removes all contentious items from the to-be-published
draft, making it accpetable to be put into a working group Last Call. Have a
very Happy Holidays, and please do contact Bob, Ed, and/or myself if you
have any questions or issues that you would like to raise before we issue a
new version of the Core Information Model draft.

regards,
John and Ed