Re: [ldapext] groupOfEntries object class proposal

[Neil Dunbar <neil.dunbar@hp.com>]

On Tuesday 18 September 2007 00:21:37 Neal-Joslin, Robert (HP-UX Lab R&D) 
wrote:

> I'm almost always in favor of new and better ways to do things.  And I
> agree with the statements submitted.  But I can see a need to play
> devil's advocate for this one.  Is there really enough justification to
> warrant this proposal?  What is the likelihood of its success, given how
> entrenched groupOfNames and groupOfUniqueNames is embedded in the
> existing LDAP application/server security space?

Well, given that there is already a choice between groupOfUniqueNames and 
groupOfNames, I find that a lot of LDAP apps tend to be parametrised around 
what OC should be considered canonical for the notion of "group". So, in this 
case, sliding in groupOfEntries wouldn't be much of a problem: at least for 
*reading* groups. For creating new ones, that might be irritating. One 
approach might be to sweep periodically and reclassify groupOfNames to 
groupOfEntries within the DIT until apps were writing groupOfEntries 
natively. Since every groupOfNames is also a valid groupOfEntries, you can't 
cause category error by expanding into the superset.

When we shifted to OpenLDAP in HP IT, pretty much all of the Sun ONE groups 
were groupOfUniqueNames - it was a well publicised flag day to shift them 
over to groupOfNames, but I'm pretty sure all apps dealt with the matter 
smoothly. We did some horrible temporary schema hacks before the move, but 
they got tossed as soon as the possibility for group Armageddon had passed 
with very few fatalities.

Cheers,

Neil
-- 
TSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited
registered Office:
 Cain Road, Bracknell, Berks
 RG12 1HN                     Registered No: 690597 England

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext