RE: [Policy] RE: PCELS position
David McTavish <dmctavish@sandvine.com> Mon, 22 September 2003 15:00 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 LAA19065 for <policy-archive@odin.ietf.org>; Mon, 22 Sep 2003 11:00:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SAV-0008GQ-Jk for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 11:00:04 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MF03Xk031719 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 11:00:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SAU-0008FT-C5; Mon, 22 Sep 2003 11:00:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1S9X-000894-SC for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:59:03 -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 KAA18951 for <policy@ietf.org>; Mon, 22 Sep 2003 10:58:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1S9Q-00007a-00 for policy@ietf.org; Mon, 22 Sep 2003 10:58:56 -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 1A1S9F-00007O-00 for policy@ietf.org; Mon, 22 Sep 2003 10:58:45 -0400
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <SZM8GMDS>; Mon, 22 Sep 2003 10:58:17 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337022B159F@mail.sandvine.com>
From: David McTavish <dmctavish@sandvine.com>
To: "'Joel M. Halpern'" <joel@stevecrocker.com>, David McTavish <dmctavish@sandvine.com>, "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, "'Pana, Mircea'" <mpana@metasolv.com>, "'policy@ietf.org'" <policy@ietf.org>
Cc: 'John Strassner' <John.Strassner@intelliden.com>
Subject: RE: [Policy] RE: PCELS position
Date: Mon, 22 Sep 2003 10:58:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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>
<Joel M. Halpern wrote> "LDAP issues are not a primary driver for model structure. Hence, I would not tend to consider LDAP issues to be a driver for reopening the discussion about changing the core model." --- I agree, and that is the root of my issue. I no longer believe that the LDAP issues are driving this, but are in fact a side-effect of the existing proposal. In my opinion, the implementation details are possibly unearthing an underlying flaw in the original PCIMe proposal. <Joel M. Halpern wrote> "If there are model level issues that were not known or discussed at the time the decision was made, we can look into re-opening the discussion. However, if we do this I will need to attempt to bring back into the discussion the other interested parties who brought forward concerns at the time (for example IPSP.)" --- Is this a viable course of action? I believe that the issue should be reconsidered, if possible. I will search through the WG archives to understand the process and consideration extended to address these issues. I do not wish to disjoint the effort and thought already invested into the proposal, but at the same time, I do wish that further discussion and pursual of alternatives can be supported to achieve the best outcome. My primary concern is that there are viable alternatives within PCIMe that could address all of its concerns, without the need to deprecate the existing model, that may have not been pursued. For example, the deprecation of the PcimRepository and all of its sub-classes may possibly have been averted. Referring to section 3.2.1 entitled "Changes to PolicyRepository", I understand that there MAY be confusion about the use of the term "Repository", however, the first course of action, IMO, would not be to deprecate schema to address this problem. I believe that this is solely a documentation issue, that can be directly addressed through an update to the documentation by providing a concise explanation of the use of repository objects and their interactions. I find that deprecating an entire model to rename "Repository" to "ReusableContainer" is addressing the problem from a more extreme vantage point than is entirely necessary. This is only my initial analysis for PCIMe, and it seems evident to me that further investigation may be warranted, if it is conceivable that such drastic measures can be avoided with fresh thinking. Regards, d. -----Original Message----- From: Joel M. Halpern [mailto:joel@stevecrocker.com] Sent: Monday, September 22, 2003 10:31 AM To: David McTavish; 'Wijnen, Bert (Bert)'; 'Pana, Mircea'; 'policy@ietf.org' Cc: 'John Strassner' Subject: RE: [Policy] RE: PCELS position We need to be very clear about the separation of issues. We are having a useful discussion about how to best represent PCIMe in LDAP. There are a number of properties of LDAP that affect this representation. At the same time it should be understood by all participants that the working group made an explicit decision to make some incompatible model changes in crafting PCIMe. While not everyone agreed with either the problems that prompted this decision or the decision itself, it did represent the rough consensus of the working group. LDAP issues are not a primary driver for model structure. Hence, I would not tend to consider LDAP issues to be a driver for reopening the discussion about changing the core model. If there are model level issues that were not known or discussed at the time the decision was made, we can look into re-opening the discussion. However, if we do this I will need to attempt to bring back into the discussion the other interested parties who brought forward concerns at the time (for example IPSP.) Yours, Joel M. Halpern, speaking as co-chair. _______________________________________________ Policy mailing list Policy@ietf.org https://www1.ietf.org/mailman/listinfo/policy
- [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