Closed Issues appendix from PCIMe

Now that PCIMe is about to be published as an RFC (really, it is! :-), it's
time to remove the appendix where we tracked the open, and then
subsequently closed, issues.  Rather than losing this information entirely,
Bert has suggested that I include it in a note to the mailing list, so that
it will be archived in a place that someone looking for it might logically
try.  So here it is:

 16. Appendix A: Closed Issues



   EDITOR'S NOTE: The following list captures the major technical issues
   that were resolved during the course of progressing PCIMe from initial
   draft to Proposed Standard.  This appendix will be removed for
submission
   to the RFC Editor (unless there is a consensus to preserve it in the
   RFC), but it should be archived somewhere.

     1.  Unrestricted use of DNF/CNF for CompoundPolicyConditions.
         Alternative: for the conditions aggregated by a
         CompoundPolicyCondition, allow only ANDing, with negation of
         individual conditions.  Note that this is sufficient to build
         multi-field packet filters from single-field
         SimplePolicyConditions.

         RESOLUTION: The same DNF/CNF capabilities present for aggregating
         PolicyConditions into a PolicyRule have been retained for
         aggregating PolicyConditions into a CompoundPolicyCondition.

     2.  For a PolicyVariable in a SimplePolicyCondition, restrict the set
         of possible values both via associated PolicyValue objects (tied
         in with the ExpectedPolicyValuesForVariable association) and via
         the ValueTypes property in the PolicyVariable class.  Alternative:
         restrict values only via associated PolicyValue objects.

         RESOLUTION: PCIMe continues to allow both mechanisms for
         restricting the values of a PolicyVariable.

     3.  Transactional semantics, including rollback, for the
         ExecutionStrategy property in PolicyRule and in
         CompoundPolicyAction.  Alternative: have only 'Do until success'
         and 'Do all'.

         RESOLUTION: No transactional semantics for action execution.  The
         value 'Mandatory Do All(1)' has been removed from the two
         ExecutionStrategy properties.

     4.  Stating that CompoundFilterConditions are the preferred way to do
         packet filtering in a PolicyCondition.  Alternative:  make
         CompoundFilterConditions and FilterEntries available to submodels,
         with no stated (or implied) preference.

         RESOLUTION: Recommendations for use of CompoundFilterConditions
         and FilterEntries are retained, but they have been recast
         slightly.  CompoundFilterConditions are now positioned as the
         recommended approach for domain-level models.  FilterEntries are
         the recommended approach for device-level models.

     5.  Prohibiting equal values for Priority within a PolicySet.
         Alternative: allow equal values, with resulting indeterminacy in
         PEP behavior.

         RESOLUTION: PCIMe will continue to prohibit equal Priority values.

     6.  Modeling a SimplePolicyAction with just a related PolicyVariable
         and PolicyValue -- the "set" or "apply" operation is implicit.
         Alternative: include an Operation property in SimplePolicyAction,
         similar to the Operation property in SimplePolicyCondition.

         RESOLUTION: This issue has been resolved by a change in the
         opposite direction.  The operations are now implicit for BOTH
         SimplePolicyCondition and SimplePolicyAction.  See Sections 5.8.3
         and 5.8.4, respectively, for discussions of
         SimplePolicyCondition's implicit MATCH operator and
         SimplePolicyAction's implicit SET operator.

     7.  Representation of PolicyValues: should values like IPv4 addresses
         be represented only as strings (as in LDAP), or natively (e.g., an
         IPv4 address would be a four-octet field) with mappings to other
         representations such as strings?

         RESOLUTION: Mappings have been eliminated.  Each value type has a
         single representation specified for it.

     8.  The nesting of rules and groups within rules introduces
         significant change and complexity in the model.  This nesting
         introduces program state (procedural language) into the model
         (heretofore a declarative model) as well as implicit hierarchical
         contexts on which the rules operate.  These require a much more
         sophisticated rule-evaluation engine than in the past.

         Alternative: Maintain the declarative model, by prohibiting
         program state in rule evaluation (i.e., no rules within rules).

         RESOLUTION: Nesting of rules and groups within rules has been
         retained, but with a significant new limitation: actions
         associated with a rule do not have side effects that would impact
         condition evaluation for subsequent rules.  "Subsequent rules"
         here includes both rules nested within the rule whose actions are
         under discussion, and rules at the same nesting level as this rule
         that are evaluated after it.  Note that it has been a feature of
         PCIM (RFC 3060) all along that condition evaluation has no side
         effects that would influence condition evaluation for subsequent
         rules.

         There is also one modeling detail associated with nesting that has
         been changed.  Rather than having separate aggregations
         (PolicyGroupInPolicyGroup, etc.) for each of the four nesting
         varieties, the single aggregation PolicySetComponent is now used
         as a concrete aggregation class.

      9. Need to specify a join algorithm for disjoint rule sets.

         RESOLUTION: PCIMe now states that for different functional domains
         (e.g., QoS and IKE), there is no join algorithm.  Each domain, in
         effect, has its own rule engine, which operates independently of
         the other domains' engine(s).  Within a functional domain,
         disjoint PolicySets are joined by the Priority property in the
         PolicySetInSystem association.  In this case the decision strategy
         is specified to be FirstMatching.

      10.  Clarify PolicyImplicitVariables.

         RESOLUTION: Each subclass of PolicyImplicitVariable will identify
         the exact source of the variable data.  For example, there will be
         a subclass of PolicyImplicitVariable that specifically identifies
         the IPv4 source address in the outermost packet header.  IPv4 and
         IPv6 addresses will require separate subclasses of
         PolicyImplicitVariable.  We understand the downside of this
         approach: a potential explosion in the number of subclasses of
         PolicyImplicitVariable.

      11.  Clarify PolicyExplicitVariables.

         NON-RESOLUTION (in PCIMe-01): This issue is still not resolved at
         all.  The authors continue to believe that we need the capability
         of indicating that a condition should compare against (or an
         action should set) a particular property in a particular object
         instance.  But we do not believe that the current mechanism of
         specifying a target object class and property name is sufficient.
         For the next version of PCIMe, we need to either find a way to
         make this work in general; or find a way to make it work in some
         cases, and then describe clearly what these cases are; or remove
         PolicyExplicitVariables from PCIMe entirely.

         RESOLUTION (in PCIMe-02): From the list of choices above, we took
         the path of making explicit variables work in a specific case, and
         indicating clearly that they work only in this case.  See Section
         5.8.6


Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email protected]