RE: [Policy] RE: PCELS position

["Joel M. Halpern" <joel@stevecrocker.com>]

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.

At 10:21 AM 9/22/2003 -0400, David McTavish wrote:
> 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


_______________________________________________
Policy mailing list
Policy@ietf.org
https://www1.ietf.org/mailman/listinfo/policy