RE: [Policy] RE: PCELS position

David McTavish <dmctavish@sandvine.com> Mon, 22 September 2003 14:24 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 KAA17067 for <policy-archive@odin.ietf.org>; Mon, 22 Sep 2003 10:24:38 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rbo-0005wz-8N for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:24:17 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MEOCnX022867 for policy-archive@odin.ietf.org; Mon, 22 Sep 2003 10:24:12 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Rbc-0005vz-VM; Mon, 22 Sep 2003 10:24:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RaN-0005qr-6E for policy@optimus.ietf.org; Mon, 22 Sep 2003 10:23:04 -0400
Received: from mail.sandvine.com (hidden-user@sandvine.com [199.243.201.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16967 for <policy@ietf.org>; Mon, 22 Sep 2003 10:22:33 -0400 (EDT)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <SZM8GL68>; Mon, 22 Sep 2003 10:21:50 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C85337022B159E@mail.sandvine.com>
From: David McTavish <dmctavish@sandvine.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 10:21:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38114.DC3A1970"
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>

With this knowledge, is it appropriate to push PCIMe back to the foreground
and determine aspects of this document that are not congruent with PCIM?
For starters, I believe section 3.1 "How to Change an Information Model"
should be re-evaluated, which could make a huge impact on the rest of the
document.  I'm not against deprecation in principal, however, I don't
believe that it should be considered as a primary option. From other models,
deprecation is usually reserved as a last resort, and even then, is fazed in
over a period of releases to allow for migration.  I don't believe that a
model that is extending from an existing model should have the right to
deprecate. If PCIMe, were actually PCIM 2.0, then I would better understand
deprecation being used, but as it stands, I am not sure this is the correct
course of action.
I'll review PCIMe document further and provide specific arguments for each
section that I believe violates the principal of PCIM, and hopefully provide
suggestions for discussion.
 
 
Regards,
d.
 
 

-----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