RE:pcimRuleConditionAssociation can contain pcimConditionAuxClass

The pcimRuleConditionAssociation was only designed to map the PCIM's PolicyRuleInPolicyCondition
aggregation. If you wanted to use conditions contained in conditions you would use the
the PCIMExtensions mapping:

www.ietf.org/internet-drafts/draft-reyes-policy-core-ext-schema-00.txt

The *AuxClass are auxiliary classes used to add or attach its attibutes to an structural class.
For instance the pcimeRuleConditionAssociation (structural class) and pcimVendorConditionAuxClass 
(auxiliary class):

	+----------------+
	|		 |
	|   pcimRule	 |
	|		 |
	+----------------+
		|
		|
		|
		|
        +-----------------------------+
	|pcimeRuleConditionAssociation|
	|   	 +                    |
	|pcimVendorConditionAuxClass  |
	+-----------------------------+

Then you have a class with the attributes of pcimeRuleConditionAssociation and
pcimVendorConditionAuxClass. Using openLDAP (www.openldap.org): first, you have to create
the pcimeRuleConditionAssociation class in a distinguished name (dn) with the command "ldapadd", then,
attach pcimeVendorconditionAuxClass to the same dn using the command "ldapmodify".

pcimeRuleauxClass and pcimGroupauxClass are auxiliary classes used to map the PCIM's 
PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup aggregations.They have to be attached to 
pcimGroupInstance(structural) class or pcimPolicyInstance if it's a reusable group (pcimPolicyInstance(structural)+
pcimGroupauxClass(auxiliary)+pcimRuleAuxClass(auxiliary)).

The conditions and actions are always attached to structural classes (pcimPolicyInstance, pcimRuleConditionAssociation
or pcimRuleActionAssociation) so they are named as *AuxClass.

>Just wondering if this association means that a condition can contain
>conditions?  It seems that all of the *AuxClass objects are used to infer
>that an object can contain child objects of type *. This seems especially
>evident via the PcimRuleAuxClass and PcimGroupAuxClass.  

>It also appears that the pcimRuleConditionAssociation is an abstract
>implementation of a core PcimCondition (on par with how a PcimRule object
>represents a rule). After reading through the draft, it seems that the
>naming convention for classes as they relate to conditions and actions are
>not 100% in-sync with rules and groups. This seems somewhat
>misleading/confusing to users of this standard, and I was wondering if there
>was any explanation/reasoning for the change in naming convention between
>these sets of objects?

>thx,
>d.