|
John,
IMO an
LDAP attribute is not defined *for* a class. An LDAP attribute defined
in the global context and then *used* by LDAP object classes.
An attribute has a syntax and (basic) semantics of its own
and these are carried over in any class that use the attribute. Then, in
the context of a class an attribute may have additional semantics. The
semantics associated by the class to an attribute are not necessarely
shared with other classes that use the attribute. Such semantics belog to
the class not the attribute.
For
example, a fictional attribute "ipv4Addresses" may be a list
of ip addresses in the x.x.x.x notation. In a "mailServer" class this
attribute may be used to store the ip addresses of this mail server. In an
"ingressFilter" class however, the same attribute may be used to match
source/dest ip addresses of ingress ip packets. Same attribute -
different class semantics.
So,
it's like saying that a Hummer and a Boat have the same type of engine even
though they use this engine in different ways (one connected to the weels,
the other to the propeller).
Regards,
Mircea.
Mircea,
The pcimRuleEnabled
attribute is defined for the pcimRule class in PCLS, and the pcimRuleEnabled
attribute is defined for the pcimPolicyRule. You claim that since the
definition of pcimRuleEnabled is the same, there should be no
problem.
I disagree
because:
1)
the semantics of the
two defining classes are different
2)
the derivation of the
two defining classes are different
It's like saying that
a Hummer and a Boat both have an engine, so why can't I use the Boat's engine
in a Hummer?
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: Tuesday, September 23, 2003 1:00
PM
To: 'John
Strassner'; 'Wijnen, Bert
(Bert)'; 'David
McTavish'; 'policy@ietf.org'
Cc: 'Joel M.
Halpern'
Subject: RE: [Policy] RE: PCELS
position
I agree with
you that an attribute should not be used in classes where it would
shift semantics. For example, the RulePriority attribute defined in PCLS
and used there by the Rule class, is not reused in PCELS. Instead, PCELS
defined a new Priority attribute for use in the realization of
PolicySetComponent and PolicySetInSystem.
However, the
attribute RuleEnabled defined in PCLS is reused in the
PolicyRule class defined by PCELS. In both classes the attribute has
identical semantics. I see nothing wrong with that.
-----Original
Message-----
From: John
Strassner [mailto:John.Strassner@intelliden.com]
Sent: Tuesday, September 23, 2003 1:03
PM
To: 'Pana, Mircea';
'Wijnen, Bert (Bert)'; 'David McTavish'; 'policy@ietf.org'
Cc: John Strassner; 'Joel M.
Halpern'
Subject: RE:
[Policy] RE: PCELS position
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
|