When I say administrator I mean whomever has administrative rights over the group in this instance i.e the group manager
Well, for well-behaved clients I think this draft goes in the right direction. However, it depends whether you include the group manager among the users or the administrators: for the group manager, complexity will increase,
Yes. However, static groups do not scale very well - in fact one of the motivations for dynamic groups was the deficiency of static group scaling. In short. put a few tens of thousands of members in a static group and things get rather slow, both client and server side. So while static group emulation is tempting from a conformance to current practice point of view, it actually exacerbates the problem.while for other users it should remain exactly the same, and the dynamic generation of part of the members should go unnoticed.
- adding/deleting members works as usual, treating them as static (aright, which breaks the existing model and existing clients.
notable exception is removing a dynamic member, which causes an error
and should actually lead to excluding the member)
- member exclusion before returning members and while comparing, andthat's a good thing (TM)
things like that are dealt with by the implementation, so it's totally
transparent to the client (either normal user or administrator)
Implicit in a nested group specification would have to be loop detection - the embodiment of that would be implementation specific. I do not believe that loop detection is impossible, I believe it may be harsh for some implementations/deployments but not impossible. Though I welcome specific examples here since distributed DITS are not my every day food.With respect to nested grouping, that's an interesting point. I would allow it for implementations that can guarantee that loops are impossible.
I understand this would need to be somehow advertised soServer options for group expansion are a recipe for confused clients and security mishaps. It is ok to have those kind of requirements if the assumption is that groups are only ever used internally to the server, but the fact is that groups are used for external reasons by clients. If that were not a usage they should never have been published as a general purpose grouping mechanism. Options based on server ability are bad when it comes to such fundamental facilities - the server just needs to do it.
that clients do not add dynamic group members to a dynamic group under
the assumption they will be expanded.
I don't think just dropping existing static groups and replacing them
with a new dynamic group would be an option, since there's too many
clients out there relying on groupOfNames and company; I don't thing
redefining it to allow dynamic groups would be an option either.
I understand your reservation on that, it isn't pretty.
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext