RE: [Policy] RE: PCELS position

[David McTavish <[e-mail]>]

Hi Bob,
Unfortunately, in LDAP, attributes must be globally unique. So, if an
attribute is defined as "foo" in one objectclass as a boolean, and as an
integer in another class, this causes an incompatibility. In some cases
(OpenLDAP), this prevents the server from even starting. It's not the most
elegant implementation, but something you get used to when working on LDAP.

Hope this is informational,
d.


-----Original Message-----
From: Robert Moore [mailto:[e-mail]]
Sent: Tuesday, September 23, 2003 1:26 PM
To: John Strassner
Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; John
Strassner; 'Pana, Mircea'; '[e-mail]'; [e-mail]
Subject: RE: [Policy] RE: PCELS position






>Furthermore, the argument that you are "reusing" an attribute foo in a new
class bar is completely specious, because the new class >bar is different
than the original class baz that defined foo. The differences are very
fundamental - different hierarchies, different >attributes, and worse
(e.g., the definition of priority). This isn't reuse, this is simply
stealing an OID.

John, I'll have to say that I'm missing the essence of your argument here.
Formally (as you've acknowledged), LDAP falls into the same category as
X.500 and CMIP: attributes are defined, and maintain their identity,
independent of the classes in which they appear.  (Digression for those who
haven't worked in the DMTF: CIM works the opposite way -- an attribute's
identity is tied to the class in which it is defined, so that it's possible
to have two attributes with identical names defined in two different CIM
classes.  This is, of course, a potential source of confusion, so there
were DMTF guidelines saying "Don't do this."  But these provided an
artificial overlay of global scope on attributes whose identity was
inherently scoped by the classes that defined them.)  I don't have specific
experience with X.500 and LDAP, but I do know that in the CMIP case it was
perfectly good practice (in fact, it was typical) to define attributes
without regard to the classes that would include them.  I'm don't see why
X.500 and LDAP should be any different.  But your use of the wording "...
the original class baz that defined foo" suggests that you see some
non-formal, but nevertheless significant sense in which LDAP attributes
*are* defined relative to the (first?) class that contains them.

Regards,
Bob

Bob Moore
WebSphere Advanced Design and Technology
WebSphere Platform System House
IBM Software Group
[phone]
[e-mail]



 

                      John Strassner

                      <John.Strassner@inte        To:       "'Pana, Mircea'"
<[e-mail]>, "'Wijnen, Bert (Bert)'"                
                      lliden.com>                  <[e-mail]>,
"'David McTavish'" <[e-mail]>, "'[e-mail]'" 
                      Sent by:                     <[e-mail]>

                      [e-mail]        cc:       John Strassner
<[e-mail]>, "'Joel M. Halpern'"           
                      g                            <[e-mail]>

                                                  Subject:  RE: [Policy] RE:
PCELS position                                               
 

                      09/23/2003 01:03 PM

 





Again, you are trying to determine the validity of an information model
based on the concerns of one specific data model. This is backwards.

Furthermore, the argument that you are "reusing" an attribute foo in a new
class bar is completely specious, because the new class bar is different
than the original class baz that defined foo. The differences are very
fundamental - different hierarchies, different attributes, and worse (e.g.,
the definition of priority). This isn't reuse, this is simply stealing an
OID.

So, how about defining a NEW set of classes and attributes? And if you
prefixes the new classes and attributes, this would also get around the
schema problem that I stated earlier.



regards,
John


John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue
Colorado Springs, CO  80906  USA
phone:  [phone]
  fax:     [phone]
email:    [e-mail]
-----Original Message-----
From: Pana, Mircea [mailto:[e-mail]]
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea;
'[e-mail]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position



Maybe there is no need for such drastic measures. Maybe it is only a matter
of interpretation of the PCIMe recommendations. After all PCIMe is quite
lenient wrt. that is and what is not used in submodels (see PCIMe section
5.10.).


Some of the structural changes proposed by PCIMe make it difficult for
PCELS to be interoperable with PCLS. These are as follows:


1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass
of the already defined PolicyRule and PolicyGroup


2. In PCIMe the PolicyRule.Priority property has been deprecated in favor
of a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new
ReusablePolicyContainer.

PCELS could be interoperable with PCLS if it was to interpret these PCIMe
changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract
PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified
PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with
no Actions or Conditions for PolicyGroup objects.


C. implementations SHOULD (as opposed to MUST) use the relative priority
mechanism instead of the absolute priority attribute of PolicyRule


D. PolicyRepository SHOULD not be used directly but it is acceptable for
instances of this class to occur through inheritance.


So, the question is whether the statements A. through D. violate PCIMe or
not. Opinions?


Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[e-mail]]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; '[e-mail]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position



W.r.t.
>  Is PCIMe considered so complete, that it is beyond modification, if such

>  modification could preserve its intent while also adhering to the
desires
> of maintaining consistency with PCIM and PCLS?


PCIMe is at Proposed Standard. If, for example because of this effort to
try and MAP it onto LDAP, we
find that we did some things in PCIMe that we should not have done, then,
with WG consensus,
we can make incompatible changes to PCIMe and then recycle at Proposed
Standard.
That is part of the normal standars track process. That is, we get
something to PS, then we start
using/implementing (the "using" part is reusing PCIMe definitions in otehr
CIM docs (like the
other docs we did in Policy, and like the IPsec work, the "implementing" is
sort of mapping onto for
example LDAP I think)... and if we find major issues, then we fix and
recycle at PS. If we do not
find major issues, we may advance to DS.


Hope this helps.
Bert



_______________________________________________
Policy mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/policy