RE: [Policy] For the record: Open Issues in PCELS-04 (all closed now)
"John Strassner" <John.Strassner@intelliden.com> Mon, 26 April 2004 06:12 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 CAA23103 for <policy-archive@odin.ietf.org>; Mon, 26 Apr 2004 02:12:16 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzIS-0001oj-2O for policy-archive@odin.ietf.org; Mon, 26 Apr 2004 02:08:52 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3Q68qSF006972 for policy-archive@odin.ietf.org; Mon, 26 Apr 2004 02:08:52 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzEk-0007UO-7k; Mon, 26 Apr 2004 02:05:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BHzCS-0005jQ-JB for policy@optimus.ietf.org; Mon, 26 Apr 2004 02:02:40 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13359 for <policy@ietf.org>; Mon, 26 Apr 2004 02:02:37 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BHzCP-0004bd-4N for policy@ietf.org; Mon, 26 Apr 2004 02:02:37 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BHzBT-0004P8-00 for policy@ietf.org; Mon, 26 Apr 2004 02:01:40 -0400
Received: from cosium03.intelliden.net ([12.41.186.100]) by ietf-mx with esmtp (Exim 4.12) id 1BHzAQ-00041V-01 for policy@ietf.org; Mon, 26 Apr 2004 02:00:35 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42B53.AEA0CBF0"
Subject: RE: [Policy] For the record: Open Issues in PCELS-04 (all closed now)
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Date: Sun, 25 Apr 2004 23:59:48 -0600
Message-ID: <AE723009E85E224CB00132C7FF0B34E1F33DFF@cosium02.intelliden.net>
Thread-Topic: [Policy] For the record: Open Issues in PCELS-04 (all closed now)
Thread-Index: AcQXL96GRw8/qR+gTl+1Qt9hTOri7QUG8jXw
From: John Strassner <John.Strassner@intelliden.com>
To: mpana@metasolv.com, policy@ietf.org
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60
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>
And for the record, I think that notes like this that document issues and their resolutions are very helpful. ;-) regards, John -----Original Message----- From: policy-admin@ietf.org [mailto:policy-admin@ietf.org] Sent: Wednesday, March 31, 2004 7:43 AM To: policy@ietf.org Subject: [Policy] For the record: Open Issues in PCELS-04 (all closed now) 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