David,
Regards,
Mircea.
> -----Original Message-----
> From: David McTavish [mailto:dmctavish@sandvine.com]
> 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'; 'policy@ietf.org'; policy-admin@ietf.org
> 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:remoore@us.ibm.com]
> Sent: Tuesday, September 23, 2003 1:26 PM
> To: John Strassner
> Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; 'policy@ietf.org'; policy-admin@ietf.org
> 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
> +1-919-254-4436
> remoore@us.ibm.com
>
>
>
>
>
> John Strassner
>
> <John.Strassner@inte To:
> "'Pana, Mircea'"
> <mpana@metasolv.com>, "'Wijnen, Bert (Bert)'"
> lliden.com>
> <bwijnen@lucent.com>,
> "'David McTavish'" <dmctavish@sandvine.com>, "'policy@ietf.org'"
> Sent by: <policy@ietf.org>
>
> policy-admin@ietf.or cc:
> John Strassner
> <John.Strassner@intelliden.com>, "'Joel M. Halpern'"
> g
> <joel@stevecrocker.com>
>
> 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: +1.719.785.0648
> fax: +1.719.785.0644
> email: john.strassner@intelliden.com
> -----Original Message-----
> From: Pana, Mircea [mailto:mpana@metasolv.com]
> Sent: Monday, September 22, 2003 8:21 AM
> To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea;
> 'policy@ietf.org'
> 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:bwijnen@lucent.com]
> Sent: Sunday, September 21, 2003 6:14 AM
> To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org'
> 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
>
>