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