Re: [ldapext] Dynamic group draft

[simo <idra@samba.org>]

On Sun, 2007-02-11 at 20:38 -0800, Pete Rowley wrote:
> Howard Chu wrote:
> > http://www.ietf.org/internet-drafts/draft-haripriya-dynamicgroup-02.txt
> >
> 
> I am pretty concerned that introducing a new group type might simply 
> further complicate the current LDAP group mess.  IMHO any addition to 
> the LDAP grouping story should unify grouping mechanisms such that 
> directly managed groups work the same way as dynamic groups from a 
> non-administrative client perspective (which admittedly this draft does 
> attempt), that nested groups be explicitly supported (because the 
> management reality is that they are required), and that the server is 
> tasked to do the work required for group membership so that the client 
> is left with simple tasks to perform normal group operations such as 
> enumeration and membership testing, and that those tasks are exactly the 
> same no matter which type of group is being examined.  LDAP groups (both 
> static and dynamic) are far too focused on the requirements for 
> server-side access control and provide very little in the way of support 
> to clients for use as a general purpose grouping mechanism - most 
> notably because those two grouping methods work in completely different 
> ways.  IOW "LDAP group" ideally should mean one thing to a client even 
> if to a server it may be many sub-types. Necessarily, this would 
> probably mean a "clean cut" from the current grouping mechanisms, and 
> yes that makes this an unlikely event, but I actually think this is 
> necessary if we are ever to get a coherent, usable, and scalable LDAP 
> group story.
> 
> These were actually some of the requirements that fed into the 
> FDS/Sun/Netscape roles feature, which I reference only as an example of 
> an approach.  In that scheme clients performing non-administrative tasks 
> have an exceptionally easy time working with roles, enumeration is a 
> search, group membership tests are a compare, there is no distinction 
> between role types at this level, everything is a DN, and yet managed, 
> dynamic, nested, and TBD can all be supported by the client with a 
> single group implementation - and all is subject to normal access 
> controls for the DIT. The server OTOH is doing quite a bit of work to 
> make this all happen, and that, IMHO, is how it should be.
> 
> Ultimately, I'd rather see nothing happen than another grouping scheme 
> that adds to the client load without showing a reasonable path to 
> grouping nirvana where current methods can be deprecated (or at least 
> not considered for future client dev).

I rarely comment, if at all, on this list, but I have to say I agree
100% with Pete's analysis and conclusions.
KISS for clients is a must.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org


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