[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Nested group (was: groupOfEntries object class proposal)
The nestedGroup attribute may not add much value. The members of the group would still need to be examined individually to determine if they in turn contain the member attribute.
-----Original Message-----
From: Andrew Findlay [mailto:andrew.findlay@skills-1st.co.uk]
Sent: Wednesday, September 19, 2007 6:47 AM
To: Steven Legg; Luke Howard; Michael Ströder
Cc: ldapext@ietf.org
Subject: [ldapext] Nested group (was: groupOfEntries object class proposal)
On Wed, Sep 19, 2007 at 09:35:41AM +1000, Steven Legg wrote:
> The advantage of *not* having nested groups is that it is sufficient
> to just read the values of the member attribute to determine group
> membership. If there are nested groups, then it is necessary to
> read each of the entries named in the values of the member attribute
> to see which of them, if any, are themselves groups. That could be
> a big performance hit for a group with a large set of members.
Good point. Servers have more options here, but a client dealing with
nested groups has to do a silly amount of work.
> If nested groups are to be allowed, then I would rather see the
> nested groups listed in a separate attribute, e.g., called nestedGroups,
> so that implementations only need to read the entries that really
> are nested groups.
That would be a great improvement in efficiency. There would also need
to be an auxiliary object class to identify groups that might contain
such attributes - nestedGroupObject or perhaps groupOfGroups.
(Or the groupOfEntries class could permit the nestedGroup attribute as
well as the member attribute. I think I would prefer a separate
class.)
On Wed, Sep 19, 2007 at 09:48:14AM +1000, Luke Howard wrote:
> This is what Novell did with eDirectory (they also have an option where
> nested members are presented as values of member).
It is certainly more efficient if the server is prepared to do things
like that, but it does require new code so it is less likely to
implemented by all servers. There is also the question of how to
manage such an entry as the client clearly cannot read the member
attributes and send updates based on what it sees.
> AD and rfc2307bis, however, simply have groups listed a values of
> member; the client is responsible for dereferencing and transiting if
> required.
There are enough performance problems with LDAP NIS group methods
already! Adding client-side nested groups can only make it worse...
On Wed, Sep 19, 2007 at 11:34:22AM +0200, Michael Ströder wrote:
> I fully agree. One really has to think twice whether nested groups are
> really needed in a particular use-case and worth the performance hit.
>
> > If nested groups are to be allowed, then I would rather see the
> > nested groups listed in a separate attribute, e.g., called nestedGroups,
> > so that implementations only need to read the entries that really
> > are nested groups.
>
> +1
It looks as if the nested groups issue needs tackling. Should I expand
this I-D to include it? The consensus seems to be:
1) groupOfEntries member attributes should not point to groups
whose members are to be considered part of the group being
described.
I see no problem with allowing them to point to groups if
expansion/nesting/inclusion is not required.
2) There should be a new aux class and attribute to support
client-side group nesting.
Servers can support group nesting in more efficient ways and
some of them already do. Should there be an attempt to
standardise the schema that supports this?
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
--------------------------------------------------------
This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext