RE: [Policy] RE: PCELS position
David McTavish <dmctavish@sandvine.com> Tue, 23 September 2003 17:57 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27625 for <policy-archive@odin.ietf.org>; Tue, 23 Sep 2003 13:57:29 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rPN-0003Cb-NI for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:57:07 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHv558012286 for policy-archive@odin.ietf.org; Tue, 23 Sep 2003 13:57:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rPI-0003BT-Ku; Tue, 23 Sep 2003 13:57:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1rOt-0003B0-Ez for policy@optimus.ietf.org; Tue, 23 Sep 2003 13:56:35 -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 NAA27582 for <policy@ietf.org>; Tue, 23 Sep 2003 13:56:27 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1rOr-0004AQ-00 for policy@ietf.org; Tue, 23 Sep 2003 13:56:33 -0400
Received: from sandvine.com ([199.243.201.138] helo=mail.sandvine.com ident=hidden-user) by ietf-mx with esmtp (Exim 4.12) id 1A1rOo-0004AM-00 for policy@ietf.org; Tue, 23 Sep 2003 13:56:30 -0400
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <SZM8GSMS>; Tue, 23 Sep 2003 13:56:29 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337022B15B1@mail.sandvine.com>
From: David McTavish <dmctavish@sandvine.com>
To: 'John Strassner' <John.Strassner@intelliden.com>, "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, David McTavish <dmctavish@sandvine.com>, "'Pana, Mircea'" <mpana@metasolv.com>, "'policy@ietf.org'" <policy@ietf.org>
Cc: "'Joel M. Halpern'" <joel@stevecrocker.com>
Subject: RE: [Policy] RE: PCELS position
Date: Tue, 23 Sep 2003 13:56:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C381FC.02D4AD60"
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>
John, I'm not suggesting fundamental changes to 3460, but rather minor modifications that relax some of the stringent requirements that were introduced. My intention is NOT to remove the new functionality added, but rather, acknowledge the stress points of PCIMe that make it incompatible with PCIM. My primary concern is that PCIMe has inadvertantly created a new standard, by implying compatibility with PCIM but not achieving it. My impression that PCIMe is supposed to be compatible was manifested by the title of the RFC, "PCIM Extensions", which in nature would imply using PCIM as a ground-work. Through my analysis, it is evident that PCIM and PCIMe are not compatible, and that this issue is NOT on an implementation level, but rather in the underlying core of the design. Going forward, if such incompatibility is allowed to manifest, there will only be a divide in the use of either standard; thereby making implementations incompatible on many fronts between PCIM and PCIMe, regardless of implementation detail. In my opinion, this jeopardizes the effort invested into either effort if they are not capable of interaction. By not acknowledging the short-comings of the incompatibilities between PCIM and PCIMe now, I believe we are doing a disservice to the community and any existing adopters. The core key issues that limit compatibility between PCIM and PCIMe are as follows: - existence of priority within rules and groups needs to be optional instead of mandatory, and allow for implied defaults - deprecation of classes {PolicyGroupInPolicyGroup, PolicyRuleInPolicyGroup} instead of extending from PolicySetContainment - renaming of data model component Repository to ReusablePolicyContainer provides no conceivable benefit, and creates incompatibility You'll note that I have no problems with the structure of PolicySet, as it appears that this is an implementation issue (perhaps resolvable via Mircea's "inferred" implementation idea). So, please, review the above points, and I think you will see that these are design issues, not implementation details, and this in fact, does create an incompatibility with PCIM. If compatibility with PCIM is NOT a requirement of PCIMe, then I submit that the name of the RFC be changed from "PCIM Extensions" to "PCIM 2.0", AND, the Abstract in RFC 3460 is modified to state up front the incompatibilities between PCIMe and PCIM. Regards, d. -----Original Message----- From: John Strassner [mailto:John.Strassner@intelliden.com] Sent: Tuesday, September 23, 2003 12:43 PM To: 'Wijnen, Bert (Bert)'; 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: John Strassner; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position Importance: High I fundamentally disagree with rebuilding RFC 3460, which is an INFORMATION MODEL, because of DATA MODEL concerns. That is exactly backwards, because it ensures that the information model cannot be mapped to other types of data models. regards, John John C. Strassner Chief Strategy Officer Intelliden Inc. 90 South Cascade Avenue Colorado Springs, CO 80906 USA phone: +1.719.785.0648 fax: +1.719.785.0644 email: john.strassner@intelliden.com -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Sunday, September 21, 2003 4:14 AM To: 'David McTavish'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner'; 'Joel M. Halpern' Subject: RE: [Policy] RE: PCELS position W.r.t. > Is PCIMe considered so complete, that it is beyond modification, if such > modification could preserve its intent while also adhering to the desires > of maintaining consistency with PCIM and PCLS? PCIMe is at Proposed Standard. If, for example because of this effort to try and MAP it onto LDAP, we find that we did some things in PCIMe that we should not have done, then, with WG consensus, we can make incompatible changes to PCIMe and then recycle at Proposed Standard. That is part of the normal standars track process. That is, we get something to PS, then we start using/implementing (the "using" part is reusing PCIMe definitions in otehr CIM docs (like the other docs we did in Policy, and like the IPsec work, the "implementing" is sort of mapping onto for example LDAP I think)... and if we find major issues, then we fix and recycle at PS. If we do not find major issues, we may advance to DS. Hope this helps. Bert
- [Policy] PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position Wijnen, Bert (Bert)
- RE: [Policy] RE: PCELS position David McTavish
- RE: [Policy] RE: PCELS position Wijnen, Bert (Bert)
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position Joel M. Halpern
- RE: [Policy] RE: PCELS position David McTavish
- RE: [Policy] RE: PCELS position John Strassner
- RE: [Policy] RE: PCELS position John Strassner
- RE: [Policy] RE: PCELS position Robert Moore
- RE: [Policy] RE: PCELS position Robert Moore
- RE: [Policy] RE: PCELS position David McTavish
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position John Strassner
- RE: [Policy] RE: PCELS position John Strassner
- RE: [Policy] RE: PCELS position John Schnizlein
- RE: [Policy] RE: PCELS position John Strassner
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position Pana, Mircea
- RE: [Policy] RE: PCELS position David McTavish
- RE: [Policy] RE: PCELS position John Strassner
- RE: [Policy] RE: PCELS position David McTavish
- RE: [Policy] RE: PCELS position David McTavish
- [Policy] RE: PCELS position David McTavish