Subject: RE: CIM24 schema tweaks

From: "Quevedo, Felix" <[email-masked]>
Date: Fri, 1 Dec 2000 14:55:19 -0000

Larry,

It looks like the dlmHelperRefTo... should actually be: dlm...HelperRef.
This must have happen when applying a "new" naming convention to the
attributes type descriptions, but did not to modify their references in the
object class descriptions.

Can the DMTF team confirm this?
Félix E Quevedo
? Smile, everything is possible!
E-Mail: [email-masked]
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	Larry S. Bartz [mailto:[email-masked]] 
Sent:	Thursday, November 30, 2000 07:42
To:	IETF Policy WG LIST
Cc:	LIST, DEN discussion; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject:	CIM24 schema tweaks

 << File: tweakedCIM24schema.txt >> My previous message on this subject was
mishandled by my mailer,
resulting in severe truncation. Here's a retry:

I have encountered some difficulties implementing the CIM v2.4 
schema, as described in the DSP0117 documents at
http://www.dmtf.org/spec/denh.html .

Since the IETF Policy WG's draft-ietf-policy-core-schema-08.txt depends 
upon the cim24 schema, experimental implementers of "schema-08" may find 
the following comments and attached edited ABNF helpful.

I am also sharing these comments with the DMTF's WG chairs and CIM
support e-mail addresses. I request that these comments be forwarded
to the appropriate individuals for review.

 - DESC - Some Directory products enforce a length limit on the 
   DESC terms of objectclass and attributeType descriptions. X.501 
   defines the limit as {ub-schema}. Annex C of X.520 defines
   {ub-schema} as 1024. DESC term values which exceed 1024 characters 
   violate this limit. Several of the descriptions in DSP0117 contain 
   DESC term values which exceed 1024 characters in length. 

 - Matching Rules - Many of the attribute descriptions in DSP0117 
   have no matching rule terms specified. The attachment nominates 
   matching rule terms where appropriate, with comments designated by 
   #LSB.

 - Unspecified Attributes - Several attribute types are nominated by
   objectClass descriptions but which have not been defined. These
   include three whose names begin with "dlmHelperRefTo...". Based on 
   a presumption that other previously-defined attributes were intended, 
   the attachment substitutes defined attribute names for those which 
   are not defined, with comments designated by #LSB.

 - Forward references precluded - The attachment relocates entries 
   in the file to avoid forward references.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email-masked]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 01 Dec 2000 13:26:24 -0500

> Can the DMTF team confirm this?

I guessed the same. I substituted the dlm...HelperRef attrs in the 
attachment to my initial message.

I've spotted another potential difficulty with the schema of DSP0117.

See this description:

attributetype    ( 1.3.6.1.4.1.412.100.1.2.1
     NAME 'orderedCimKeys'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
     EQUALITY octetStringMatch
   )

The matching rule syntax does not match the attribute's syntax. This 
must be corrected.

---

From: "Larry S. Bartz" <[email-masked]>
Date: Fri, 01 Dec 2000 14:33:25 -0500

Since there is no "public" forum for discussion of the dlm1/CIM24 LDAP
schema, I'm forwarding these comments through various DMTF Working Group
chairs. Please forward these comments to your working group members as
you deem appropriate.

Since the IETF's Policy WG has such a close working relationship with
the
DMTF WGs, I'm sharing these comments with the Policy WG, as well.

--

The attributes dlmPrimaryOwnerName and dlmPrimaryOwnerContact do not
adequately leverage the potential of the Directory information model.
These attributes of the objectclass dlm1System are defined as
directoryString types.

If the "primary owner" is not represented in the Directory (or a 
federated Directory instance), these string values may adequately
serve their purpose. This could be considered "best effort" information.

In a thorough Directory implementation, it is likely that the
"primary owner" will be represented with a Directory entry. This
could be via objectclasses such as person, organizationalUnit, 
organizationalRole, or similar.

In such cases, the "primary owner(s)" should be identified by a
distinguishedName (DN) -type attribute.

By leveraging Directory-based information about "primary owner",
clients can discover and use specific and strongly-typed attribute
values such as e-mail, URL, and phone numbers for voice, fax, pager, 
and mobile .   

The next iteration of the dlm/CIM schema should support an additional
attribute of distinguishedName (DN) type, an attribute to augment
the "primary owner" notion of the information model. The attribute
could be named dlmPrimaryOwnerDN. This attributeType should allow
multiple values.

Similar rationale applies to the dlmSupportAccess objectclass. If
the supporting entity is represented in the Directory (or federated
Directory instance), it should be identified by a distinguishedName 
(DN) -type attribute.

The next iteration of the dlm/CIM schema should support an additional
attribute of distinguishedName (DN) type, an attribute to augment
the "support entity" notion of the information model. The attribute
could be named dlmSupportAccessDN. This attributeType should allow
multiple values.

Thank you for your consideration of this issue.

---

From: "Lee Rafalow" <[email-masked]>
Date: Fri, 1 Dec 2000 16:41:58 -0500

Larry, these mailing lists seem fine for having this discussion.  The Policy
Core LDAP Schema draft references the CIM Core mapping so it's relevent.
(Joel, Ed, if you disagree, let us know and we'll find another forum.)

The CIM user-security model (see http://www.dmtf.org/spec/cims.html ) has
three associations of interest that augment the primary owner name and
contact properties.  (An argument could be made that these properties should
be deprecated, but that hasn't been done as yet.)  The SystemAdministrator,
SystemAdministratorRole and SystemAdministratorGroup associations define
relationships between a System and a UserEntity (in CIM, Person and
UsersAccess are subclasses of UserEntity), Role and Group respectively.

The mapping of the CIM user-security model to an LDAP schema is in process
right now.  The Person, Role and Group objects will be mapped directly to
familiar LDAP classes.  If you look at the way associations are mapped in
the Core mapping, you'll see that the preferred way of doing these
associations would be to have an aux class of the association, e.g.,
dlm1SystemAdminsitratorAuxClass, attached to both a Person instance (e.g.,
inetOrgPerson) with a DN pointer back to the system,
dlmSystemAdministratorAntecedentRef, and attached to a system instance with
a DN pointer to the Person, dlmSystemAdministratorDependentRef.

We haven't gotten to the Support model yet.  I hope this helps.  Cheers, Lee

----- Original Message -----
From: "Larry S. Bartz" <[email-masked]>
Cc: "IETF Policy WG LIST" <[email-masked]>; "LIST, DEN discussion"
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, December 01, 2000 2:33 PM
Subject: dlm1/CIM24 schema suggestion