Trouble with attributes - WAS: RE: PCLS classes deprecat ed in PCELS
John Strassner <[email protected]> Wed, 17 Sep 2003 11:42:33 -0600
| Newsgroups | gmane.ietf.policy |
|---|---|
| Message-ID | <[email protected]> |
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 protected] -----Original Message----- From: Pana, Mircea [mailto:[email protected]] Sent: Wednesday, September 17, 2003 10:03 AM To: 'John Strassner'; 'Joel M. Halpern'; 'Larry S. Bartz'; '[email protected]' Cc: '[email protected]'; 'David McTavish' Subject: RE: [Policy] PCLS classes deprecated in PCELS John, see <mircea2>..</mircea2> Thanks, Mircea. -----Original Message----- From: John Strassner [mailto:[email protected]] Sent: Tuesday, September 16, 2003 11:22 PM To: 'Pana, Mircea'; John Strassner; 'Joel M. Halpern'; 'Larry S. Bartz'; '[email protected]' Cc: '[email protected]'; '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 protected] -----Original Message----- From: Pana, Mircea [mailto:[email protected]] Sent: Monday, September 15, 2003 4:21 PM To: 'John Strassner'; 'Joel M. Halpern'; Larry S. Bartz; '[email protected]' Cc: [email protected]; 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 protected] <mailto:[email protected]> ] Sent: Monday, September 15, 2003 9:15 AM To: Pana, Mircea; 'Joel M. Halpern'; Larry S. Bartz; '[email protected]' Cc: [email protected]; 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 protected] -----Original Message----- From: Pana, Mircea [mailto:[email protected] <mailto:[email protected]> ] Sent: Friday, September 12, 2003 3:11 PM To: 'Joel M. Halpern'; Larry S. Bartz; '[email protected]' Cc: [email protected]; 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 protected] <mailto:[email protected]> ] > Sent: Friday, September 12, 2003 1:50 PM > To: Larry S. Bartz; '[email protected]' > Cc: [email protected]; 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 protected] > https://www1.ietf.org/mailman/listinfo/policy <https://www1.ietf.org/mailman/listinfo/policy> >