Subject: Trouble with attributes - WAS: RE: [Policy] PCLS classes deprecat ed in PCELS

From: John Strassner <[email-masked]>
Date: Wed, 17 Sep 2003 11:42:33 -0600

Since it is now one point, I'm bringing that up immediately below this
sentence so people can find it. :-)

John originally wrote:
With respect to your first point, PCELS does NOT already do this everywhere
- for example, there are cases where you've changed the name of the PCLS
class but kept the names of its attributes. That's very bad and will result
in some NASTY errors. 

Mircea replied:
<mircea> 
Can you please give an example from the current PCELS? I don't understand
what you mean by "changed the name of the PCLS class". Except for pcimGroup*
and the PCLS classes marked as deprecated (that will be changed as noted)
there are concepts that have been redefined (i.e. new classes introduced by
PCELS with new OIDs). Some use attributes defined by PCLS. Do you see
anything wrong with that?</mircea>

John replied back:
<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines
pcimPolicyRule with a set of 10 optional attributes. Of these, five of the
PCELS attributes have the same name as the corresponding PCLS attributes,
yet you have deprecated pcimRule. How is that possible?
</js> 

Mircea replied back:
<mircea2>The five attributes with the same name are the ones defined by
PCLS. They are NOT redefined by PCELS, they are reused in their original
form and with their original semantics. PCELS provides replacement for the
pcimRule class and 5 of its 11 attributes. (The currently published revision
of PCELS explicitly deprecates the class and five of its 11 attributes and
the next revision will replace that with a note explicitly listing the
replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in
PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

John's hopefully final reply:
<js2>
This is unacceptable, because: (1) you should simply reference the PCLS
definition, not repeat it, and (2) you have the same attribute defined by
two different object classes. Servers that have already implemented PCLS
will find this a conflict, and react in strange and wonderful ways. For
example, if you search for one of the original 5 PCLS attributes, you will
get hits from the PCLS class (which you deprecated) and the PCELS class.
Servers don't understand deprecation. Worse, if you don't scope your search
correctly, and deleted old instances of the PCLS class, you'll still get
hits but they won't be able to trace what the object class was since it was
deleted.

I strongly recommend that you do NOT do this. If you make a new object
class, make a new attribute. And add text in the descriptions that say that
something was deprecated for something else.
</js>

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    [email-masked]

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Wednesday, September 17, 2003 10:03 AM
To: 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; [email-masked]'
Cc: [email-masked]'; 'David McTavish'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

John,

see <mircea2>..</mircea2>

Thanks,

Mircea.

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, September 16, 2003 11:22 PM
To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz';
[email-masked]'
Cc: [email-masked]'; 'David McTavish'
Subject: RE: [Policy] PCLS classes deprecated in PCELS

Hi there...

regards,
John

John C. Strassner

Chief Strategy Officer

Intelliden Inc.

90 South Cascade Avenue

Colorado Springs, CO  80906  USA

phone:  +1.791.785.0648

  fax:     +1.719.785.0644

email:    [email-masked]

-----Original Message-----
From: Pana, Mircea [mailto:[email-masked]] 
Sent: Monday, September 15, 2003 4:21 PM
To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; [email-masked]'
Cc: [email-masked]; David McTavish
Subject: RE: [Policy] PCLS classes deprecated in PCELS

John, 

Thanks for the detailed comments and suggestions. This is greatly
appreciated. As already noted, there will be a PCELS revision shortly. This
revision will take into account the suggestions that you and the other
participants made on the list.

There are a few clarifications that I'd like to ask for. See below in
<mircea>..</mircea>. 

-----Original Message----- 
From: John Strassner [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Monday, September 15, 2003 9:15 AM 
To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; [email-masked]' 
Cc: [email-masked]; David McTavish 
Subject: RE: [Policy] PCLS classes deprecated in PCELS 

With respect to your first point, PCELS does NOT already do this everywhere
- for example, there are cases where you've changed the name of the PCLS
class but kept the names of its attributes. That's very bad and will result
in some NASTY errors. 

<mircea> 
Can you please give an example from the current PCELS? I don't understand
what you mean by "changed the name of the PCLS class". Except for pcimGroup*
and the PCLS classes marked as deprecated (that will be changed as noted)
there are concepts that have been redefined (i.e. new classes introduced by
PCELS with new OIDs). Some use attributes defined by PCLS. Do you see
anything wrong with that?</mircea>

<js>
PCLS defines pcimRule with a set of 11 optional attributes. PCELS defines
pcimPolicyRule with a set of 10 optional attributes. Of these, five of the
PCELS attributes have the same name as the corresponding PCLS attributes,
yet you have deprecated pcimRule. How is that possible?
</js> 

<mircea2>The five attributes with the same name are the ones defined by
PCLS. They are NOT redefined by PCELS, they are reused in their original
form and with their original semantics. PCELS provides replacement for the
pcimRule class and 5 of its 11 attributes. (The currently published revision
of PCELS explicitly deprecates the class and five of its 11 attributes and
the next revision will replace that with a note explicitly listing the
replaced items, as discussed). Of the remaining 6 attributes of pcimRule, in
PCELS, 5 are used by pcimPolicyRule and one by pcimPolicySet.</mircea2> 

With respect to the second point, that's much better. I will provide
comments on the schema itself next week. 

With respect to naming, I don't understand the problem. You have build a new
design, not an update of an existing design. Thus, new concepts should be
assigned a new prefix (and I'd prefer pcels, instead of pcime) whereas
existing concepts should be assigned the pcim prefix. Thus, it is not a
"everything or nothing" decision but instead a judicious application of new
(pcels) vs old (pcim) concepts.

<mircea> 
I have heard valid arguments for using a different naming prefix in PCELS
than the one used by PCLS. These arguments are based on the view that
PCIM/PCLS is the "core" while PCIMe/PCELS is an "extension". This is one
point of view. Mine is that PCIM/PCLS alone is incomplete and that only
*together* with PCIMe/PCELS it provides THE Framework for the development of
domain specific submodels. Both produced by the same WG btw. (I'm not going
to argue that though - it seems to be a sore spot!) For me, the naming
prefix is a minor issue and I can live with a different prefix if people are
so strongly against reuse.

<js>
I disagree with your statement that PCIM/PCLS is incomplete. You have
already heard that many people have built implementations.   I think that
the goal has to be interoperability and peaceful coexistence between PCLS
and PCELS implementations.
</js> 

<mircea2>Peace! I totally agree that, to the extent posible,
interoperability with the original schema and a peaceful coexistence should
be (and will be) the goals of PCELS ;-)</mircea2>   

Thanks, 
Mircea. 
</mircea> 

regards, 
John 

John C. Strassner 
Chief Strategy Officer 
Intelliden Inc. 
90 South Cascade Avenue 
Colorado Springs, CO  80906  USA 
phone:  +1.791.785.0648 
  fax:     +1.719.785.0644 
email:    [email-masked] 

-----Original Message----- 
From: Pana, Mircea [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, September 12, 2003 3:11 PM 
To: 'Joel M. Halpern'; Larry S. Bartz; [email-masked]' 
Cc: [email-masked]; David McTavish 
Subject: RE: [Policy] PCLS classes deprecated in PCELS 

So, if I understand correctly, everything would be "OK" if PCELS did: 
1. Define only subclasses of PCLS classes and, where not possible, redefine
PCLS concepts as new classes (use different names and oid.s). This is
already the case in the currently published ID with the exception of
pcimGroup* that would need to be redefined with a different name.  

2. Use "for compliance with PCIMe implementations SHALL use <list schema
items> instead of <list of schema items> for the realization of <concepts>"
instead of deprecating PCLS classes. This would be added to a new revision
of the ID.

I'm fine with both. (I hope I did not miss anything) 
Wrt. naming PCELS classes and attributes pcime* instead of pcim*, as long as
there are no naming conflicts, I would prefer to avoid it if possible. Could
you live with that? However if we have to do it for one item we should do it
for all.

Thanks, 
Mircea. 

> -----Original Message----- 
> From: Joel M. Halpern [mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Friday, September 12, 2003 1:50 PM 
> To: Larry S. Bartz; [email-masked]' 
> Cc: [email-masked]; David McTavish; Pana, Mircea 
> Subject: Re: [Policy] PCLS classes deprecated in PCELS 
> 
> 
> Ryan as just nicely explained this to me in a way that got it 
> through my 
> thick skull.  You both are correct.  We can not move existing classes. 
> 
> Hence, one needs to create new classes, and include text that 
> says "use 
> this instead of the old thing". 
> 
> Unfortunate, but really a common problem with class naming / 
> inheritance 
> (not specific to just LDAP). 
> 
> As I said to Ryan, thanks for the patience explaining this. 
> Joel 
> 
> At 12:39 PM 9/12/2003 -0500, Larry S. Bartz wrote: 
> >Ryan Moats wrote, On 09/12/03 11:27: 
> >[snip} 
> >>Actually, that is a solution for all of the subclass cases: 
> in PCELS call 
> >>tem pcime*, give them different OIDs from what's in PCLS 
> and then everything 
> >>is ok. 
> > 
> >I'll go further and suggest that every component of PCIMe which is 
> >not exactly as defined in PCLS should be prefixed "pcime". If PCELS 
> >simply avoids deprecating, renaming, or redefining anything from 
> >PCLS, there can be no conflict with PCLS. And if everything new 
> >which is introduced by PCELS is prefixed "pcime", there can be no 
> >confusion about which is "core" and which is "extension". 
> > 
> >Such a strategy will ultimately satisfy Joel's concerns, 
> when he wrote: 
> > > My feeling is that concerns about PCELS should be in the 
> context of 
> > > support for PCIMe, 
> >and 
> > > if one can accurately map PCIMe to LDAP in a way that is 
> compatible 
> > > with PCLS, then that would clearly seem desirable 
> > 
> >PCELS should map PCIMe to LDAP in a way which is not 
> INcompatible with 
> >PCLS, in a way which does not break PCLS. I agree that 
> "concerns about 
> >PCELS should be in the context of support for PCIMe". I augment that 
> >by saying that PCELS should not be concerned with recasting PCLS in 
> >any way. 
> > 
> >PCELS should focus on mapping PCIMe to LDAP. PCELS should avoid any 
> >impact on PCLS. 
> > 
> > 
> >-- 
> >-- 
> >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 
> ::::::::::| 
> ># Larry Bartz 
> ># 
> >#  voice (317) 226-7060 
> >#  FAX   (317) 226-6378 
> >#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 
> ::::::::::| 
> 
> 
> 
> _______________________________________________ 
> Policy mailing list 
> [email-masked] 
> https://www1.ietf.org/mailman/listinfo/policy
<https://www1.ietf.org/mailman/listinfo/policy>