RE: [Policy] RE: PCELS position

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

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.

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



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:  [phone] 
  fax:     [phone] 
email:    [e-mail] 

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

 

John,

 

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.

 

Mircea.

 

 

 

-----Original Message-----
From: John Strassner [mailto:[e-mail]]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish';
'[e-mail]'
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:  [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]
<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