RE: [Policy] RE: PCELS position

["Pana, Mircea" <[e-mail]>]

David,

Regards,
Mircea.

> -----Original Message-----
> From: David McTavish [mailto:[e-mail]]
> Sent: Tuesday, September 23, 2003 1:33 PM
> To: 'Robert Moore'; 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
> 
> 
> Hi Bob,
> Unfortunately, in LDAP, attributes must be globally unique.
I don't think this is unfortunate ;-)

> 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
This should be prevented from happening but it is a matter of server
implementation. To be compliant with LDAP one must stick to the syntax
globally defined for the attribute.
 
> 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.
You make it sound so painful ;-)

> 
> 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
> 
>