RE: [Policy] RE: PCELS position

[John Strassner <[e-mail]>]

I'm saying:

  1) that an information model should not be driven by the 
     concerns of a single data model, and
  2) I do not believe that the word "reuse" applies when an
     attribute is defined in one class, with one set of 
     semantics, and then is blopped into a new class with
     completely different semantics. That is what I meant
     by stealing an OID.

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: Robert Moore [mailto:[e-mail]]
> Sent: Tuesday, September 23, 2003 11:40 AM
> To: David McTavish
> Cc: 'Wijnen, Bert (Bert)'; David McTavish; 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; '[e-mail]'; [e-mail]
> Subject: RE: [Policy] RE: PCELS position
> 
> 
> 
> 
> 
> David,
> 
> Yes, that's exactly what I was saying.  What I don't understand is
> this: if
> LDAP attributes are globally unique, what's the problem with
> reusing them
> in multiple classes (with the same syntax and semantics, of
> course)?  This
> was a desirable thing in CMIP, but John is suggesting that it's to
> be
> avoided in LDAP.
> 
> Regards,
> Bob
> 
> Bob Moore
> WebSphere Advanced Design and Technology
> WebSphere Platform System House
> IBM Software Group
> [phone]
> [e-mail]
> 
> 
> 
> 
>                       David McTavish
>                       <dmctavish@sandvi        To:       Robert
> Moore/Raleigh/IBM@IBMUS, John Strassner
>                       ne.com>
> <[e-mail]>
>                                                cc:       "'Wijnen,
> Bert (Bert)'" <[e-mail]>, David McTavish
>                       09/23/2003 01:33
> <[e-mail]>, "'Joel M. Halpern'"
> <[e-mail]>, John Strassner
>                       PM
> <[e-mail]>, "'Pana, Mircea'"
> <[e-mail]>,
>                                                 "'[e-mail]'"
> <[e-mail]>, [e-mail]
>                                                Subject:  RE:
> [Policy] RE: PCELS position
> 
> 
> 
> 
> 
> 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
> 
>