[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