Subject: [Policy] PCELS position

From: "Pana, Mircea" <[email-masked]>
Date: Fri, 19 Sep 2003 16:33:33 -0500

After having read so many arguments on the position of PCELS relative to
PCLS I've come to the conclusion that people wish PCELS to be either a fully
interoperable extension of PCLS or a stand-alone policy schema. At the same
time the main goal of PCELS was to implement PCIMe (as an increment of
PCIM).

Based on these facts, I can see three major options (and perhaps a lot of
variations):
1. If PCELS ignores or alters some of the PCIMe recommendations, then it can
be fully interoperable with PCLS.
2. For PCELS to be fully compliant with PCIMe it must at the minimum define
replacement for a couple of the schema items defined by PCLS.
3. For PCELS to be fully compliant with PCIMe and stand-alone (i.e. no
dependency on PCLS), it would need to redefine many (otherwise re-usable)
PCLS schema items.

So, my question to the group is: of the three options above, which one do
you like the most (or find the easiest to live with)?

Joel, is #1 a viable option?

Thank you,
Mircea.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 21 Sep 2003 12:14:19 +0200

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

---

From: David McTavish <[email-masked]>
Date: Mon, 22 Sep 2003 10:21:49 -0400

With this knowledge, is it appropriate to push PCIMe back to the foreground
and determine aspects of this document that are not congruent with PCIM?
For starters, I believe section 3.1 "How to Change an Information Model"
should be re-evaluated, which could make a huge impact on the rest of the
document.  I'm not against deprecation in principal, however, I don't
believe that it should be considered as a primary option. From other models,
deprecation is usually reserved as a last resort, and even then, is fazed in
over a period of releases to allow for migration.  I don't believe that a
model that is extending from an existing model should have the right to
deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand
deprecation being used, but as it stands, I am not sure this is the correct
course of action.
I'll review PCIMe document further and provide specific arguments for each
section that I believe violates the principal of PCIM, and hopefully provide
suggestions for discussion.

Regards,
d.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

> 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

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 22 Sep 2003 16:27:37 +0200

However, let me add that it is probably not OK (but that is the WG chairs who
decide) to re-open issues that have been beated to dead in the past and for
which there is no new data to consider. 
 
I probably should have said that with my earlier email.

Thanks,
Bert 

-----Original Message-----
From: David McTavish [mailto:[email-masked]]
Sent: maandag 22 september 2003 16:22
To: 'Wijnen, Bert (Bert)'; David McTavish; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

With this knowledge, is it appropriate to push PCIMe back to the foreground and determine aspects of this document that are not congruent with PCIM?
For starters, I believe section 3.1 "How to Change an Information Model" should be re-evaluated, which could make a huge impact on the rest of the document.  I'm not against deprecation in principal, however, I don't believe that it should be considered as a primary option. From other models, deprecation is usually reserved as a last resort, and even then, is fazed in over a period of releases to allow for migration.  I don't believe that a model that is extending from an existing model should have the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand deprecation being used, but as it stands, I am not sure this is the correct course of action.
I'll review PCIMe document further and provide specific arguments for each section that I believe violates the principal of PCIM, and hopefully provide suggestions for discussion.

Regards,
d.

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

Hope this helps.
Bert

---

From: "Pana, Mircea" <[email-masked]>
Date: Mon, 22 Sep 2003 09:20:48 -0500

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:[email-masked]]
Sent: Sunday, September 21, 2003 6:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

Hope this helps.
Bert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 22 Sep 2003 10:30:30 -0400

We need to be very clear about the separation of issues.

We are having a useful discussion about how to best represent PCIMe in 
LDAP.  There are a number of properties of LDAP that affect this 
representation.

At the same time it should be understood by all participants that the 
working group made an explicit decision to make some incompatible model 
changes in crafting PCIMe.  While not everyone agreed with either the 
problems that prompted this decision or the decision itself, it did 
represent the rough consensus of the working group.  LDAP issues are not a 
primary driver for model structure.  Hence, I would not tend to consider 
LDAP issues to be a driver for reopening the discussion about changing the 
core model.

If there are model level issues that were not known or discussed at the 
time the decision was made, we can look into re-opening the 
discussion.  However, if we do this I will need to attempt to bring back 
into the discussion the other interested parties who brought forward 
concerns at the time (for example IPSP.)

Yours,
Joel M. Halpern, speaking as co-chair.

At 10:21 AM 9/22/2003 -0400, David McTavish wrote:
>With this knowledge, is it appropriate to push PCIMe back to the 
>foreground and determine aspects of this document that are not congruent 
>with PCIM?
>believe that it should be considered as a primary option. From other 
>models, deprecation is usually reserved as a last resort, and even then, 
>is fazed in over a period of releases to allow for migration.  I don't 
>believe that a model that is extending from an existing model should have 
>the right to deprecate. If PCIMe, were actually PCIM 2.0, then I would 
>better understand deprecation being used, but as it stands, I am not sure 
>this is the correct course of action.
>section that I believe violates the principal of PCIM, and hopefully 
>provide suggestions for discussion.
>
>
>Regards,
>d.
>
>

_______________________________________________
Policy mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy

---

From: David McTavish <[email-masked]>
Date: Mon, 22 Sep 2003 10:58:16 -0400

<Joel M. Halpern wrote>
"LDAP issues are not a primary driver for model structure.  Hence, I would
not tend to consider 
LDAP issues to be a driver for reopening the discussion about changing the
core model."

---
I agree, and that is the root of my issue. I no longer believe that the LDAP
issues are driving this, but are in fact a side-effect of the existing
proposal. In my opinion, the implementation details are possibly unearthing
an underlying flaw in the original PCIMe proposal. 

<Joel M. Halpern wrote>
"If there are model level issues that were not known or discussed at the 
time the decision was made, we can look into re-opening the 
discussion.  However, if we do this I will need to attempt to bring back 
into the discussion the other interested parties who brought forward 
concerns at the time (for example IPSP.)"

---
Is this a viable course of action?  I believe that the issue should be
reconsidered, if possible.  I will search through the WG archives to
understand the process and consideration extended to address these issues.
I do not wish to disjoint the effort and thought already invested into the
proposal, but at the same time, I do wish that further discussion and
pursual of alternatives can be supported to achieve the best outcome.  My
primary concern is that there are viable alternatives within PCIMe that
could address all of its concerns, without the need to deprecate the
existing model, that may have not been pursued. 

For example, the deprecation of the PcimRepository and all of its
sub-classes may possibly have been averted. Referring to section 3.2.1
entitled "Changes to PolicyRepository", I understand that there MAY be
confusion about the use of the term "Repository", however, the first course
of action, IMO, would not be to deprecate schema to address this problem. I
believe that this is solely a documentation issue, that can be directly
addressed through an update to the documentation by providing a concise
explanation of the use of repository objects and their interactions. I find
that deprecating an entire model to rename "Repository" to
"ReusableContainer" is addressing the problem from a more extreme vantage
point than is entirely necessary. 

This is only my initial analysis for PCIMe, and it seems evident to me that
further investigation may be warranted, if it is conceivable that such
drastic measures can be avoided with fresh thinking.

Regards,
d.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Monday, September 22, 2003 10:31 AM
To: David McTavish; 'Wijnen, Bert (Bert)'; 'Pana, Mircea';
[email-masked]'
Cc: 'John Strassner'

Yours,

---

From: John Strassner <[email-masked]>
Date: Tue, 23 Sep 2003 10:43:19 -0600

I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION
MODEL, because of DATA MODEL concerns. That is exactly backwards, because it
ensures that the information model cannot be mapped to other types of data
models.

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:    [email-masked] 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

Hope this helps.

Bert

---

From: David McTavish <[email-masked]>
Date: Tue, 23 Sep 2003 13:56:27 -0400

John,
 
I'm not suggesting fundamental changes to 3460, but rather minor
modifications that relax some of the stringent requirements that were
introduced.  My intention is NOT to remove the new functionality added, but
rather, acknowledge the stress points of PCIMe that make it incompatible
with PCIM.  My primary concern is that PCIMe has inadvertantly created a new
standard, by implying compatibility with PCIM but not achieving it.  My
impression that PCIMe is supposed to be compatible was manifested by the
title of the RFC, "PCIM Extensions", which in nature would imply using PCIM
as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are
not compatible, and that this issue is NOT on an implementation level, but
rather in the underlying core of the design. Going forward, if such
incompatibility is allowed to manifest, there will only be a divide in the
use of either standard; thereby making implementations incompatible on many
fronts between PCIM and PCIMe, regardless of implementation detail. In my
opinion, this jeopardizes the effort invested into either effort if they are
not capable of interaction.  By not acknowledging the short-comings of the
incompatibilities between PCIM and PCIMe now, I believe we are doing a
disservice to the community and any existing adopters.
 
The core key issues that limit compatibility between PCIM and PCIMe are as
follows:
 - existence of priority within rules and groups needs to be optional
instead of mandatory, and allow for implied defaults
 - deprecation of classes {PolicyGroupInPolicyGroup,
PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment
 - renaming of data model component Repository to ReusablePolicyContainer
provides no conceivable benefit, and creates incompatibility
 
You'll note that I have no problems with the structure of PolicySet, as it
appears that this is an implementation issue (perhaps resolvable via
Mircea's "inferred" implementation idea). So, please, review the above
points, and I think you will see that these are design issues, not
implementation details, and this in fact, does create an incompatibility
with PCIM. 
 
If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that
the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND,
the Abstract in RFC 3460 is modified to state up front the incompatibilities
between PCIMe and PCIM.
 
Regards,
d.

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

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

Hope this helps.

Bert

---

From: "Pana, Mircea" <[email-masked]>
Date: Tue, 23 Sep 2003 13:59:36 -0500

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:[email-masked]]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'

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 

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

  

Thanks, 
Mircea. 
-----Original Message----- 
From: Wijnen, Bert (Bert) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Sunday, September 21, 2003 6:14 AM 
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]' 
Cc: 'John Strassner'; 'Joel M. Halpern' 
Subject: RE: [Policy] RE: PCELS position 

W.r.t. 

Hope this helps. 
Bert

---

From: John Strassner <[email-masked]>
Date: Tue, 23 Sep 2003 13:11:36 -0600

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 

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2003 1:00 PM
To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'
Cc: 'Joel M. Halpern'

John,

Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

  

Thanks, 
Mircea. 
-----Original Message----- 
From: Wijnen, Bert (Bert) [mailto:[email-masked]

W.r.t. 

Hope this helps. 
Bert

---

From: John Strassner <[email-masked]>
Date: Tue, 23 Sep 2003 13:24:36 -0600

Hi David,

Thanks for a thoughtful response, even if my original posting wasn't
directed specifically at you. :-)

I believe that the root of the problem lies in the wording of PCIMe. I note
that in PCLS, the dreaded priority rule attribute is NOT mandatory, viz:

     ( IANA-ASSIGNED-OID.1.5 NAME 'pcimRule'

            DESC 'The base class for representing the "If Condition

                  then Action" semantics associated with a policy rule.'

            SUP pcimPolicy            

            ABSTRACT

            MAY ( pcimRuleName $ pcimRuleEnabled $ 

                  pcimRuleConditionListType $ pcimRuleConditionList $  

                  pcimRuleActionList $ pcimRuleValidityPeriodList $  

                  pcimRuleUsage $ pcimRulePriority $  

                  pcimRuleMandatory $ pcimRuleSequencedActions $  

                  pcimRoles )

     )

Hopefully, we've already agreed that deprecation is a Bad Thing in a schema.
And I completely agree with your third issue - as a co-author of PCIMe, I
voted against this change as I couldn't understand the logic, but was out
voted. I note that this falls under the area of Bert's "don't bring it up
again".

At this point, I need to reread your thorough analyses and possibly 3460 and
3060 to see what went wrong. Although I hope that the PCELS authors will
reply before me, especially since my time is rather limited this week.

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: David McTavish [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2003 11:56 AM
To: 'John Strassner'; 'Wijnen, Bert (Bert)'; David McTavish; 'Pana, Mircea';
[email-masked]'
Cc: 'Joel M. Halpern'

John,

Regards,

d.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 12:43 PM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea';
[email-masked]'

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

Hope this helps.

Bert

---

From: John Schnizlein <[email-masked]>
Date: Tue, 23 Sep 2003 15:53:33 -0400

At 03:11 PM 9/23/2003, John Strassner wrote:

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

Aren't Chrysler V-8 engines used in both some boats and SUVs?
The transmissions are different, but as long as the external
parameters of the object (torque, horsepower, etc.) match,
an engine is an engine.

John

Not sure this helps, but the metaphor seem apt.

---

From: John Strassner <[email-masked]>
Date: Tue, 23 Sep 2003 13:58:37 -0600

That only obfuscates the problem, which is violating OO design principles.

regards,
John

John C. Strassner
Chief Strategy Officer
Intelliden Inc.
90 South Cascade Avenue

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Tuesday, September 23, 2003 1:54 PM
> To: John Strassner
> Cc: [email-masked]'

---

From: "Pana, Mircea" <[email-masked]>
Date: Tue, 23 Sep 2003 16:58:17 -0500

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:[email-masked]]
Sent: Tuesday, September 23, 2003 3:12 PM
To: 'Pana, Mircea'; John Strassner; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'
Cc: 'Joel M. Halpern'

Mircea,

I disagree because:

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2003 1:00 PM
To: 'John Strassner'; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'
Cc: 'Joel M. Halpern'

John,

Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

  

Thanks, 
Mircea. 
-----Original Message----- 

W.r.t. 

Hope this helps. 
Bert

---

From: "Pana, Mircea" <[email-masked]>
Date: Tue, 23 Sep 2003 17:12:33 -0500

I agree with John. The mapping of an information model to a data model has
its own chalenges and the chalenges will be different from one technology to
an other. That does not mean that we have to revisit the model each time.
 
I am not trying to say that PCIMe is perfect and that it should never be
revisited, but I do not see (so far) enough reasons for re-opening such
discussions. 
 
Regards,
Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 12:43 PM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea';
[email-masked]'

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Sunday, September 21, 2003 4:14 AM
To: 'David McTavish'; 'Pana, Mircea'; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

W.r.t.

Hope this helps.

Bert

---

From: "Pana, Mircea" <[email-masked]>
Date: Tue, 23 Sep 2003 17:44:45 -0500

I have probably not expressed myself clearly. My intent was to highlight a
few areas where PCELS has difficulty mapping PCIMe in a manner that would be
compatible with PCLS. Further I crafted an interpretation (in lack of better
wording) of the model that, if applied to the LDAP mapping, would alleviate
the problem. I was not trying to challenge the model but to find the right
interpretation (or compromise I should say).
 
Regards,
Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 1:03 PM
To: 'Pana, Mircea'; 'Wijnen, Bert (Bert)'; 'David McTavish';
[email-masked]'

regards,
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 22, 2003 8:21 AM
To: 'Wijnen, Bert (Bert)'; 'David McTavish'; Pana, Mircea; [email-masked]'
Cc: 'John Strassner'; 'Joel M. Halpern'
Subject: RE: [Policy] RE: PCELS position

  

Thanks, 
Mircea. 
-----Original Message----- 

W.r.t. 

Hope this helps. 
Bert

---

From: "Pana, Mircea" <[email-masked]>
Date: Tue, 23 Sep 2003 17:51:02 -0500

David,

Regards,
Mircea.

> 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'; [email-masked]'; [email-masked]
> 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.
> 
> 
> From: Robert Moore [mailto:[email-masked]]
> Sent: Tuesday, September 23, 2003 1:26 PM
> To: John Strassner
> Cc: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Joel M. Halpern'; John
> Strassner; 'Pana, Mircea'; [email-masked]'; [email-masked]
> class bar is completely specious, because the new class >bar 
> is different
> 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
> [email-masked]
> 
> 
> 
>  
> 
>                       John Strassner
> 
>                       <John.Strassner@inte        To:       
> "'Pana, Mircea'"
> <[email-masked]>, "'Wijnen, Bert (Bert)'"                
>                       lliden.com>                  
> <[email-masked]>,
> "'David McTavish'" <[email-masked]>, "[email-masked]'" 
>                       Sent by:                     <[email-masked]>
> 
>                       [email-masked]        cc:       
> John Strassner
> <[email-masked]>, "'Joel M. Halpern'"           
>                       g                            
> <[email-masked]>
> 
>                                                   Subject:  
> RE: [Policy] RE:
> PCELS position                                               
>  
> 
>                       09/23/2003 01:03 PM
> 
>  
> 
> 
> 
> 
> 
> Some of the structural changes proposed by PCIMe make it difficult for
> PCELS to be interoperable with PCLS. These are as follows:
> 
> 
> 2. In PCIMe the PolicyRule.Priority property has been 
> deprecated in favor
> of a new relative priority mechanism.
> PCIMe is at Proposed Standard. If, for example because of 
> this effort to
> try and MAP it onto LDAP, we

---

From: "Pana, Mircea" <[email-masked]>
Date: Tue, 23 Sep 2003 20:46:50 -0500

John,

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

I do not understand the difference in semantics that you are referring to. 

Let's take pcimRuleEnables one more time as example. PCLS defines it as:
"An integer indicating whether a policy rule is administratively enabled
(value=1), disabled (value=2), or enabled for debug (value=3)". In PCLS this
attribute indicates the state of pcimRule, class mapped from PCIM's
PolicyRule. In PCELS we use (but not redefine) this attribute preserving its
its syntax and semantics to indicate the state of a pcimPolicyRule, class
mapped from PCIMe's PolicyRule. Doesn't the attribute (I stress: the
attribute not the class that uses it) have the same semantics in these two
cases?

Regards,
Mircea.

---

From: David McTavish <[email-masked]>
Date: Wed, 24 Sep 2003 11:30:09 -0400

One example of attribute re-use is the x500UniqueIdentifier attribute, which
is defined in RFC 2256, and again used in inetOrgPerson RFC 2798.
 
d.

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 9:47 PM
To: 'John Strassner '; ''Robert Moore' '
Cc: ''Wijnen, Bert (Bert)' '; ''David McTavish' '; ''Joel M. Halpern' ';
Pana, Mircea; [email-masked]' '
Subject: RE: [Policy] RE: PCELS position

 John, 

Regards, 
Mircea.

---

From: John Strassner <[email-masked]>
Date: Tue, 23 Sep 2003 11:51:01 -0600

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

> Sent: Tuesday, September 23, 2003 11:40 AM
> To: David McTavish
> 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
>                       David McTavish
>                       <dmctavish@sandvi        To:       Robert
> Moore/Raleigh/IBM@IBMUS, John Strassner
>                       ne.com>
> <[email-masked]>
>                                                cc:       "'Wijnen,
> Bert (Bert)'" <[email-masked]>, David McTavish
>                       09/23/2003 01:33
> <[email-masked]>, "'Joel M. Halpern'"
> <[email-masked]>, John Strassner
>                       PM
> <[email-masked]>, "'Pana, Mircea'"
> <[email-masked]>,
>                                                 "[email-masked]'"
> <[email-masked]>, [email-masked]
>                                                Subject:  RE:
> 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.
> 
> class bar is completely specious, because the new class >bar is
> different
> independent of the classes in which they appear.  (Digression for
> those who
> identity is tied to the class in which it is defined, so that it's
> possible
> classes.  This is, of course, a potential source of confusion, so
> there
> 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
> without regard to the classes that would include them.  I'm don't
> see why
>                       <John.Strassner@inte        To:       "'Pana,
> Mircea'"
>                       [email-masked]        cc:       John
> Strassner
>                                                   Subject:  RE:
> [Policy]
> RE:
> 2. In PCIMe the PolicyRule.Priority property has been deprecated in
> favor
> >  modification could preserve its intent while also adhering to
> the
> desires
> PCIMe is at Proposed Standard. If, for example because of this
> effort to

---

From: David McTavish <[email-masked]>
Date: Tue, 23 Sep 2003 13:58:46 -0400

Bob,

Pardon my confusion. From my experience, re-using attributes within multiple
objectclasses is a valid strategy provided that the meaning of the attribute
is maintained, and is in fact encouraged by existing RFC's (for example:
x500UniqueIdentifier is identified in RFC 2256, and re-used in RFC 2798
(inetOrgPerson)).

Regards,
d.

-----Original Message-----
From: Robert Moore [mailto:[email-masked]]
Sent: Tuesday, September 23, 2003 1:40 PM
To: David McTavish
Cc: 'Wijnen, Bert (Bert)'; David McTavish; 'Joel M. Halpern'; John

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