RE: [Policy] RE: PCELS position

"Pana, Mircea" <mpana@metasolv.com> Mon, 22 September 2003 14:32 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 KAA17781 for <policy-archive@odin.ietf.org>; Mon, 22 Sep 2003 10:32:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RjO-0006Tn-Jp for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:32:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEW2jp024863 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:32:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RjO-0006Sv-Aa; Mon, 22 Sep 2003 10:32:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rip-0006Pr-Ni for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:31:27 -0400
Received: from srvmaddog.metasolv.com (mail.metasolv.com [12.105.131.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17643 for <policy@ietf.org>; Mon, 22 Sep 2003 10:31:17 -0400 (EDT)
Received: by SRVMADDOG with Internet Mail Service (5.5.2655.55) id <S0L0S7S9>; Mon, 22 Sep 2003 09:30:03 -0500
Message-ID: <A33EE5A81E634B488B099FD31F65196153CDE4@srvotemail.metasolv.com>
From: "Pana, Mircea" <mpana@metasolv.com>
To: "'Wijnen, Bert (Bert)'" <bwijnen@lucent.com>, 'David McTavish' <dmctavish@sandvine.com>, "Pana, Mircea" <mpana@metasolv.com>, "'policy@ietf.org'" <policy@ietf.org>
Cc: 'John Strassner' <John.Strassner@intelliden.com>, "'Joel M. Halpern'" <joel@stevecrocker.com>
Subject: RE: [Policy] RE: PCELS position
Date: Mon, 22 Sep 2003 09:20:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38114.B848BE90"
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>

Maybe there is no need for such drastic measures. Maybe it is only a matter
of interpretation of the PCIMe recommendations. After all PCIMe is quite
lenient wrt. that is and what is not used in submodels (see PCIMe section
5.10.).

Some of the structural changes proposed by PCIMe make it difficult for PCELS
to be interoperable with PCLS. These are as follows:
1. PCIMe defines a new abstract class, PolicySet, and makes it a superclass
of the already defined PolicyRule and PolicyGroup
2. In PCIMe the PolicyRule.Priority property has been deprecated in favor of
a new relative priority mechanism.
3. PolicyRepository is deprecated in favor of the new
ReusablePolicyContainer.
 
PCELS could be interoperable with PCLS if it was to interpret these PCIMe
changes as follows:
A. there is no need to have an explicit LDAP mapping of the abstract
PolicySet. (see also B.)
B. there is no need to have an explicit LDAP mapping of the modified
PolicyGroup. Implementations can use (the equivalent of) a PolicyRule with
no Actions or Conditions for PolicyGroup objects.
C. implementations SHOULD (as opposed to MUST) use the relative priority
mechanism instead of the absolute priority attribute of PolicyRule
D. PolicyRepository SHOULD not be used directly but it is acceptable for
instances of this class to occur through inheritance.

So, the question is whether the statements A. through D. violate PCIMe or
not. Opinions?

Thanks,
Mircea.
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Sunday, September 21, 2003 6: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