[Policy] For the record: Open Issues in PCELS-04 (all closed now)

mpana@metasolv.com Wed, 31 March 2004 14:54 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25007 for <policy-archive@odin.ietf.org>; Wed, 31 Mar 2004 09:54:08 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h65-0001ia-Lt for policy-archive@odin.ietf.org; Wed, 31 Mar 2004 09:53:41 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VErf1E006596 for policy-archive@odin.ietf.org; Wed, 31 Mar 2004 09:53:41 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h5R-0001bg-Fq; Wed, 31 Mar 2004 09:53:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8h4X-0001Zk-Ve for policy@optimus.ietf.org; Wed, 31 Mar 2004 09:52:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24800 for <policy@ietf.org>; Wed, 31 Mar 2004 09:52:02 -0500 (EST)
From: mpana@metasolv.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8h4W-00031e-00 for policy@ietf.org; Wed, 31 Mar 2004 09:52:04 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8h3X-0002xo-00 for policy@ietf.org; Wed, 31 Mar 2004 09:51:05 -0500
Received: from passwd.metasolv.com ([216.30.145.17] helo=srvplemail2.metasolv.com) by ietf-mx with esmtp (Exim 4.12) id 1B8h2u-0002tL-00 for policy@ietf.org; Wed, 31 Mar 2004 09:50:24 -0500
Received: by passwd.metasolv.com with Internet Mail Service (5.5.2653.19) id <HGKS6TL9>; Wed, 31 Mar 2004 08:50:34 -0600
Message-ID: <A33EE5A81E634B488B099FD31F65196101241D06@srvotemail.metasolv.com>
To: policy@ietf.org
Date: Wed, 31 Mar 2004 08:42:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4172E.6DAD1290"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NEW_DOMAIN_EXTENSIONS,NO_REAL_NAME autolearn=no version=2.60
Subject: [Policy] For the record: Open Issues in PCELS-04 (all closed now)
Sender: policy-admin@ietf.org
Errors-To: policy-admin@ietf.org
X-BeenThere: policy@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=unsubscribe>
List-Id: Policy Framework <policy.ietf.org>
List-Post: <mailto:policy@ietf.org>
List-Help: <mailto:policy-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/policy>, <mailto:policy-request@ietf.org?subject=subscribe>

The following section was included in the previous revision of PCELS but it
has been removed in the current (-05) revision. For the record, these are
the PCELS-04 Open Issues (now all closed):

Appendix B: Open Issues

   1. Should RFC 2119 be cited as normative reference? PCIM_EXT, PCLS
   and other documents refer to RFC 2119 as an informative reference.
   RESOLUTION: RFC2119 is cited as normative reference.

   2. The object classes pcelsVendorVariable and pcelsVendorValue
   defined in this document are not mapped from PCIM_EXT. 
   Pro: It is estimated that non-standard submodels and their LDAP
   schema implementations will need to define a considerable number of
   new PolicyVariable and PolicyValue subtypes. In order to avoid an
   explosion of LDAP class definitions, the pcelsVendorVariable and
   pcelsVendorValue classes introduce a value based extension mechanism
   for handling new data types. These classes do not introduce a new
   concept but rather a new extension mechanism for an existing concept.
   A similar mechanism is defined by PCIM and implemented by PCLS for
   creating vendor specific PolicyCondition and PolicyAction entries.
   Con: Since PCIM_EXT does not define such classes this document should
   not do it either. The purpose of this document this document is to
   map the PCIM_EXT model to an LDAP schema, therefore such
   functionality is outside its scope.
   RESOLUTION: classes preserved
   
   3. PolicyGroup is not explicitly mapped to an LDAP object class.
   Pro: Since the PolicyRule has now the capability to aggregate other
   PolicyRule instances, this class includes the functionality of the
   PolicyGroup. Therefore, an explicitly implementation of the
   PolicyGroup class is unnecessary.
   Con: The PolicyRule and the PolicyGroup have different semantics so
   they should be defined using different classes.
   RESOLUTION: PolicyGroup is explicitly mapped to pcelsGroup.

   4. pcelsReusableContainer is defined as a subclass of pcimRepository.
   Therefore the new class is an extension to the old one, not an
   alternative to it.
   Pro: As a subclass of pcimRepository, pcelsReusableContainer
   is compatible with older implementations that expect containers of
   reusable policy elements to be implemented as pcimRepository
   entries. The new class extends the functionality of the
   pcimRepository class by implementing the ContainedDomain aggregation.
   Con: pcelsReusableContainer as subclass of pcimRepository has
   potentially detrimental implications on Object Oriented models.
   RESOLUTION: inheritance from pcimRepository preserved

   5. pcelsConditionAssociation is defined as a subclass of
   pcimRuleConditionAssociation. It extends the applicability of 
   the old class to the aggregation of PolicyContition instances as
   components of CompoundPolicyContitions.
   Pro: The Condition aggregation mechanism can be reused in both Rule
   and CompoundCondition, therefore making it possible to optimize 
   their implementation.
   Con: Mapping of the PCIM_EXT aggregations is implicit therefore more
   difficult for some implementations to detect.
   RESOLUTION: current implementation preserved