Re: [ldapext] Dynamic group draft

[Pete Rowley <prowley@redhat.com>]

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).

--
Pete

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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