Re: [ldapext] LDAP Groups topic split-out
Jordan Brown <Jordan.Brown@oracle.com> Fri, 04 December 2015 00:33 UTC
Return-Path: <Jordan.Brown@oracle.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD34F1B2B59 for <ldapext@ietfa.amsl.com>; Thu, 3 Dec 2015 16:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrSfLjbMBMId for <ldapext@ietfa.amsl.com>; Thu, 3 Dec 2015 16:33:50 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5251B2B54 for <ldapext@ietf.org>; Thu, 3 Dec 2015 16:33:49 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB40XiaH026140 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Dec 2015 00:33:45 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tB40XiFh001426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 00:33:44 GMT
Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id tB40Xits003664; Fri, 4 Dec 2015 00:33:44 GMT
Received: from [10.159.138.9] (/10.159.138.9) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 03 Dec 2015 16:33:44 -0800
To: Charlie <medievalist@gmail.com>, ldapext <ldapext@ietf.org>
References: <CAJb3uA57jHCfhN6tQB6Kc7uOGF3g4w6GVmr6+OnhD4=k5zqEzw@mail.gmail.com>
From: Jordan Brown <Jordan.Brown@oracle.com>
Message-ID: <5660DF62.5000800@oracle.com>
Date: Thu, 03 Dec 2015 16:33:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <CAJb3uA57jHCfhN6tQB6Kc7uOGF3g4w6GVmr6+OnhD4=k5zqEzw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/vLaXRf-JUFuqKLxEP7CYAX5q9bE>
Subject: Re: [ldapext] LDAP Groups topic split-out
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 00:33:52 -0000
On 12/3/2015 3:12 PM, Charlie wrote: > After reading David Foster Wallace on set theory, I wrote an RFC a > couple years back to address the lack of a generic or globally useful > grouping mechanism in LDAP-accessible directories. Comments are > welcomed. > > http://typinganimal.net/rants/textify.php?f=draft-brooks-ldap-sets-00.txt 3.1. Properly, Boy Scout and Scout are capitalized. In the general case, I'd say that it's equally correct to say that the list of Scouts is an attribute of the troop and to say that membership in the troop is an attribute of the particular Scout. It's an N:M relationship; it can be approached from either direction. (I had not realized until I got to the discussion in D.2 that a mailing list was best served by member-of attributes. One would think that it would be best served by a member-list attribute, but you're absolutely correct that using a member-of attribute reduces the number of queries in the common case.) For an indexed database, it's probably OK to represent the relationship in either direction. For a database that understands the relationship, the relationship might be visible on both sides and the connection automatically maintained. For simpler databases, indeed maintaining "member-of" is probably better, both because it's convenient for the common queries and because it's probably a smaller list than the "members" list. (But note: it's not at all obvious which variation is better from an access control standpoint. Is it more likely that you will want to hide the membership of group X, or the list of groups that user Y is a member of? Presumably if you want to do either, then you need to ensure that that membership linkage, however it is presented in the directory, is subject to access control restrictions.) 3.4. Empty sets are also useful in trivial cases, e.g. when creating a set and before populating, and as a possible intermediate state while adding and removing members. 3.5 I'm not convinced that "proxy" objects (which you call "dummy" objects) aren't the right answer. Directly referring to external objects assumes that there's no need for auxiliary data about those objects. (Hmm. Is there a need to describe auxiliary information about a particular membership relationship? For instance, for a mailing list, might one want to maintain a count of messages from a particular list to a particular user that have bounced?) 4.4 I'm not convinced that an undefined "scope" attribute is helpful. 4.5 psetMembership seems like overkill, though its ability to represent dynamic sets is interesting. 5.3 If recursion is always expanded by the client, there's no need for timeouts on queries to prevent DoS. The clients can decide on their own when to stop recursing. C.1, C.2 I thought that memberOfPset contained DNs. D.5 posixGroup has memberUid as a MAY attribute and so *can* represent empty sets. > If you're not up for a long-read, I would recommend just reading > "Appendix D: Other Efforts and their Shortcomings" which explains all > the attempts to date and how they've failed to gain traction. > > Projects continue to try to solve their individual problems instead of > working towards a truly generic grouping mechanism that will suit all > needs, so nothing's progressing. Simo mentioned this in the context > of FreeIPA, for example - they broke their implementation of RFC2307 > and moved on, rather than helping Andrew Findlay create a standard > that supported empty groups. It seems like each of us is focused on > our own potato patch. > Actually, here in the Solaris Naming organization, mostly our assumption is that we have to live with whatever the directory gives us, that the directory was established by the enterprise before we arrived on the scene and so our ability to influence it is minimal. We might participate in an effort such as this one to try to nudge the future in a desirable direction, but the assumption is that no one scheme will ever achieve such dominance that we can ignore the others. Of course I would be happy to be proven wrong so that we could remove a bunch of flexibility that's associated with the need to interoperate with such a variety of schemata.
- [ldapext] LDAP Groups topic split-out Charlie
- Re: [ldapext] LDAP Groups topic split-out Jordan Brown
- Re: [ldapext] LDAP Groups topic split-out Michael Ströder
- Re: [ldapext] LDAP Groups topic split-out Simo Sorce
- Re: [ldapext] LDAP Groups topic split-out Michael Ströder
- Re: [ldapext] LDAP Groups topic split-out Simo Sorce
- Re: [ldapext] LDAP Groups topic split-out Charlie