Subject: [Policy] RE: Trouble with attributes

From: "Pana, Mircea" <[email-masked]>
Date: Thu, 18 Sep 2003 11:56:26 -0500

John,
 
I feel obliged to respond to this message since I have a very different
opinion. Feel free to ignore it if you consider this a waste of your time.
 
Respectfully,
Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz';
[email-masked]'
Cc: [email-masked]'; 'David McTavish'
Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat
ed in PCELS

Since it is now one point, I'm bringing that up immediately below this
sentence so people can find it. :-)

John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere
- for example, there are cases where you've changed the name of the PCLS
class but kept the names of its attributes. That's very bad and will result
in some NASTY errors. 

Mircea replied:
<mircea> 
Can you please give an example from the current PCELS? I don't understand
what you mean by "changed the name of the PCLS class". Except for pcimGroup*
and the PCLS classes marked as deprecated (that will be changed as noted)
there are concepts that have been redefined (i.e. new classes introduced by
PCELS with new OIDs). Some use attributes defined by PCLS. Do you see
anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines
pcimPolicyRule with a set of 10 optional attributes. Of these, five of the
PCELS attributes have the same name as the corresponding PCLS attributes,
yet you have deprecated pcimRule. How is that possible?
</js> 

Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by
PCLS. They are NOT redefined by PCELS, they are reused in their original
form and with their original semantics. PCELS provides replacement for the
pcimRule class and 5 of its 11 attributes. (The currently published revision
of PCELS explicitly deprecates the class and five of its 11 attributes and
the next revision will replace that with a note explicitly listing the
replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in
PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS
definition, not repeat it, and (2) you have the same attribute defined by
two different object classes. Servers that have already implemented PCLS
will find this a conflict, and react in strange and wonderful ways. For
example, if you search for one of the original 5 PCLS attributes, you will
get hits from the PCLS class (which you deprecated) and the PCELS class.
Servers don't understand deprecation. Worse, if you don't scope your search
correctly, and deleted old instances of the PCLS class, you'll still get
hits but they won't be able to trace what the object class was since it was
deleted.

I strongly recommend that you do NOT do this. If you make a new object
class, make a new attribute. And add text in the descriptions that say that
something was deprecated for something else.
</js> 

Yet Mircea replies: 

<mircea3>

BTW: I am commenting on PCELS -03 published in August 2003.

On (1) above:

 The attributes/classes defined in PCLS and used in PCELS are referenced,
NOT repeated. See for example: "Its attributes are defined in the section
5.4 of the [PCLS]." on page 27 of PCELS. I admit that there might be places
where PCELS fails to make explicit references but any repetition of PCLS
definitions in PCELS is unintentional and should be considered an editorial
error.

On (2) above:

- LDAP attributes are not defined by classes. LDAP Attributes are used by
classes and they can be used by any number of classes. LDAP attributes
defined by standard schemas may be (and are) reused by a number of standard
LDAP classes ('cn' would the trivial example). I am not aware of any
restriction imposed by the LDAP or X.500 standards at this level. On the
contrary, I think that the intent was to encourage attribute reuse.

- An application that searches for entries with a specific attribute and
expects to be able to make sense of all the entries returned in the search
results is a poorly designed application. At the minimum, this application
should check for the appropriate objectclass either by including it in the
search filter or by filtering out non-matching entries from the result set.

</mircea3> 

Respectfully,
Mircea.

---

From: John Strassner <[email-masked]>
Date: Thu, 18 Sep 2003 11:29:40 -0600

Mircea,

Perhaps I should have been clearer. I agree, there's nothing in LDAP or
X.500 that prevents you doing what you've done. My point was that in my
opinion, it is a poor design to do that.

Trust me, I know how to write an LDAP filter. :-)  But you're putting all of
the burden on the client in your approach. Furthermore, how are you going to
write your schema? PCELS is, in my opinion, not an extension but rather a
redesign. This is fine, but in this case I would have expected to see a
stand-alone schema for PCELS. Does that make sense?

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    [email-masked]

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; [email-masked]'
Subject: RE: Trouble with attributes

John,

Respectfully,

Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz';
[email-masked]'

John originally wrote:

Mircea replied:
<mircea> 

John replied back:
<js>

Mircea replied back:

Yet Mircea replies: 

<mircea3>

On (1) above:

On (2) above:

</mircea3> 

Respectfully,

Mircea.

---

From: David McTavish <[email-masked]>
Date: Thu, 18 Sep 2003 16:30:24 -0400

I've decided to supplement my previous email with some in-depth analysis of
the proposed PCELS to act as a guide in how to bridge the two standards.
Please note, that this is not an extensive review, as sections 5.25 through
5.31 warrant an alternate thread altogether (in which I would argue that
alot of these characteristics should inherit from RFC 2307 with some careful
extensions), and I'd prefer to open that can of worms at a later date. :)
 
Please discuss the following suggestions, as I believe they encompass what
PCIMe is trying to accomplish, while preserving prior effort from PCIM. I
apologize that I haven't outlined WHY I'm suggesting the following, as I'm
hoping that review of the suggestions against both drafts will explain.
However, if anyone has any questions in regard to some of the tactics I'm
suggesting (proposing to use auxiliary classes to extend existing PCIM
classes instead of deprecating and creating a new class), please direct to
the list to flesh these ideas out.
 
5.1 pcimPolicySet <removed>            - use existing pcimGroup object
    pcimPolicySetName <removed>        - use existing pcimGroupName attr
    pcimPriority <removed>             - use new pcimGroupPriority attr
    pcimPolicySetList <removed>        - use combination of existing
pcimGroupsAuxContainedSet and pcimRulesAuxContainedSet
    pcimDecisionStrategy <retained>
    pcimGroupPriorityAuxClass <added>
    pcimGroupPriority <added>
    pcimDecisionStrategyAuxClass <added>
    pcimGroupRolesAuxClass <added>
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimGroupPriorityAuxClass'
    DESC 'Auxiliary class that represents a level of priority for a
particular group.'
    SUP pcimGroup
    AUXILIARY
    MAY { pcimGroupPriority }
   }
 
{ IANA-ASSIGNED-OID.2.x
    NAME 'pcimGroupPriority'
    DESC 'Group priority.'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
    SINGLE-VALUE
   )

{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimDecisionStrategyAuxClass'
    DESC 'Auxiliary class that enables a rule or group to contain decision
and execution strategy symantecs.'
    SUP pcimPolicy
    AUXILIARY
    MAY { pcimDecisionStrategy }
   }
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimGroupRolesAuxClass'
    DESC 'Auxiliary class that enables a group to contain role-based
information.'
    SUP pcimGroup
    AUXILIARY
    MAY { pcimRoles }
   }
 
5.2 pcimPolicySetAssociation <removed>    - use existing pcimGroupInstance
object
    pcimPriority <removed>                - use suggested pcimGroupPriority
as above
    pcimPolicySetDN <removed>             - use 
5.3 <removed>
5.4 <removed>
5.5 <removed>
5.6 pcimPolicyRule <removed>              - use existing pcimRule object
    pcimPolicyRuleAuxClass <removed>      - use existing pcimRuleAuxClass
    pcimPolicyRuleInstance <removed>      - use existing pcimRuleInstance
    pcimConditionListType <removed>       - use existing
pcimRuleConditionListType
    pcimConditionList <removed>           - use existing
pcimRuleConditionList
    pcimActionList <removed>              - use existing pcimRuleActionList
    pcimSequencedActions <removed>        - use existing
pcimRuleSequencedActions
    pcimExecutionStrategy <retained>
    pcimExecutionStrategyAuxClass <added>
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimExecutionStrategyAuxClass'
    DESC 'Auxiliary class that enables a rule to contain execution strategy
information.'
    SUP pcimRule
    AUXILIARY
    MAY { pcimExecutionStrategy }
   }
 
5.7 pcimConditionAssociation <removed>    - use existing
pcimRuleConditionAssociation
5.8 pcimActionAssociation <removed>       - use existing
pcimRuleActionAssociation
5.9 <removed>
5.10 <removed>
5.11 <removed>
5.12 pcimSimpleConditionAuxClass <retained>
5.13 pcimCompoundConditionAuxClass <retained>
5.14 pcimCompoundFilterConditionAuxClass <retained> although, I'd like some
explanation of what this is for...
5.15 pcimSimpleActionAuxClass <retained>
5.16 pcimCompoundActionAuxClass <retained>
5.17 pcimVariable <retained>
5.18 pcimExplicitVariableAuxClass <retained>
5.19 pcimImplicitVariableAuxClass <retained>
5.20 is merged with 5.19 to follow pattern of previous sections containing
attributes
     pcim*AuxClass <removed>
5.21 <retained>
5.22 <retained>
5.23 pcimReusableContainer <removed>         - use existing pcimRepository
     pcimReusableContainerAuxClass <removed> - use existing
pcimRepositoryAuxClass
     pcimReusableContainerInstance <removed> - use existing
pcimRepositoryInstance
     pcimReusableContainerName <removed>     - use existing
pcimRepositoryName
     pcimReusableContainerList <removed>     - use new pcimRepositoryList
     pcimRepositoryContainmentAuxClass <added>
     pcimRepositoryList <added>

{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimRepositoryContainmentAuxClass'
    DESC 'Auxiliary class that enables an object to aggregate reusable
repository containers.'
    SUP pcimRepositoryAuxClass
    AUXILIARY
    MAY { pcimRepositoryList }
   }
 
{ IANA-ASSIGNED-OID.1.x
    NAME 'pcimRepositoryList'
    DESC 'blah blah blah...'
    EQUALITY caseIgnoreMatch
    ORDERING caseIgnoreOrderingMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    SINGLE-VALUE
   }
 
5.24 <removed>

Regards,
d.

---

From: John Strassner <[email-masked]>
Date: Thu, 18 Sep 2003 13:01:28 -0600

Resending due to mail delivery failure...

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

-----Original Message-----
From: John Strassner 
Sent: Thursday, September 18, 2003 11:30 AM
To: 'Pana, Mircea'; John Strassner; [email-masked]'
Subject: [Policy] RE: Trouble with attributes

Mircea,

 

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; [email-masked]'
Subject: RE: Trouble with attributes

John,

Respectfully,

Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz';
[email-masked]'

John originally wrote:

Mircea replied:
<mircea> 

John replied back:
<js>

Mircea replied back:

Yet Mircea replies: 

<mircea3>

On (1) above:

On (2) above:

</mircea3> 

Respectfully,

Mircea.

---

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

John,

There are many design techniques that lead to attribute "mixtures" within a
same entry and the possilities for something to go wrong are countless. I
don't see why attribute re-use would be evil ;-) while subclasses or aux.
class attachment would not. We just need to design our applications in the
idea that a shared repository is always a source of surprises.

Regards,
Mircea.

 -----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Thursday, September 18, 2003 1:30 PM
To: 'Pana, Mircea'; John Strassner; [email-masked]'
Subject: RE: Trouble with attributes

Mircea,

Trust me, I know how to write an LDAP filter. J  But you're putting all of

regards,
John

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

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Thursday, September 18, 2003 10:56 AM
To: 'John Strassner'; [email-masked]'
Subject: RE: Trouble with attributes

John,

Respectfully,
Mircea.
-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, September 17, 2003 1:43 PM
To: Pana, Mircea; 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz';
[email-masked]'
sentence so people can find it. J

Yet Mircea replies: 
<mircea3>

Respectfully,
Mircea.

---

From: David McTavish <[email-masked]>
Date: Mon, 22 Sep 2003 13:46:13 -0400

I agree with Mircea in this regard. I have no problem with a particular LDAP
class having multiple auxiliary classes which may have overlapping
attributes. Searching LDAP should focus on matching the desired objectClass
instead of on an attribute level. The only problem I could foresee is if
each auxiliary class inferred a different meaning into the values specified
in the overlapping attribute, but seeming that the description for the
attribute is embedded directly to the attribute, this should not be the
case.
 
d.

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]]
Sent: Monday, September 22, 2003 1:09 PM
To: John Strassner; [email-masked]'
Subject: [Policy] RE: Trouble with attributes

John, 

Regards, 
Mircea. 

 -----Original Message----- 
From: John Strassner [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, September 18, 2003 1:30 PM 
To: 'Pana, Mircea'; John Strassner; [email-masked]' 
Subject: RE: Trouble with attributes 

Mircea, 

regards, 
John 

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

-----Original Message----- 
From: Pana, Mircea [ mailto:[email-masked] <mailto:[email-masked]> ]

John, 

Respectfully, 
Mircea. 
-----Original Message----- 
From: John Strassner [ mailto:[email-masked]
<mailto:[email-masked]> ] 

Mircea replied: 
<mircea> 

John replied back: 
<js> 

</js> 
Mircea replied back: 

</js> 

Yet Mircea replies: 
<mircea3> 

On (2) above: 

</mircea3> 

Respectfully, 
Mircea.