Group Practices Survey 
Email response from Robert Banz, University of Maryland, Baltimore County
August 9, 2001

A. Please address each of the following items. It would be especially 
interesting to relate how the nature of particular planned or deployed 
applications constrains your choices in each of these areas.

A.1. How is group membership (to be) represented? Are any of the following types 
used? What led you to decide on the membership representation(s) you've chosen?

We currently only use static groups in our directory, simply from an ease-of-use 
perspective on the application side -- easy to query the groups someone is in, 
or who is in that group.

A.2. What objectclass(es) do you (anticipate) using to instantiate group 
objects, if you indeed (plan to) instantiate group objects: groupOfNames, 
groupOfUniqueNames, groupOfURLs, other perhaps custom object class(es)?

Currently using groupOfUniqueNames, or classes which are derived from it.

If you (will) use a custom group objectclass, what functional requirements drive 
the design of the group schema?


A.3. How are group memberships (to be) maintained? Automated processes? By hand? 
Using what tools?

They're currently either updated automagically from our source data feeds, but 
some are updated by web tools.

Do (or will) you maintain referential integrity, i.e., if an object is removed 
from the directory, are its group memberships also removed? How?

Currently, our tools/libraries that we use on our directory search for, and 'do 
the right thing' when we're renaming, or deleting something. Would like to look 
at using a server-side plugin for this in the future.


A.4. Can group objects be members of groups? What object types can be members of 
groups?

Some of our administrative applications do this, and theoretically 'do the right 
thing' if something that's a 'groupOfUniqueNames' is listed.  Since this 
activity is application-driven, instead of a simple LDAP query, it's a bit of a 
pain.

A.5. Do you (expect to) have a mechanism for representing a group whose 
membership is the result of an automated process together with a manually 
maintained set of exceptions (either inclusive or exclusive)?

Yes. How?  Probably application driven...  That's a tough one to represent.

Does (or will) your implementation support any other forms of "group 
arithmetic", i.e., set theoretic operations on the membership lists of a 
collection of groups? 

....it probably should.

A.6. What policy pertains (will pertain) to administration of group membership?

Certain groups are machine generated, others aren't.  The policy regarding the 
administration of the 'others' is controlled by our web administration 
applicaitons, which get their directions from -- well - group memberships :)

Is administration of groups (to be) delegated?

Through the applications.

How is the set of groups (to be) groomed, i.e., stale ones made to go away 
eventually?

Haven't had to do it yet...

A.7. What privacy or security policy pertains (will pertain) to any of your 
groups? Are there policies that prohibit or inhibit the existence of certain 
types of groups?

As far as accessing the contents of the groups -- access is granted to list, or 
check membership via compare, on a per-group, per-application basis -- some are 
more public than others, though.  The only policies that would inhibit the 
existence of groups would be if they were requested to be public, but one would 
be able to glean 'protected' data from them about a user/users.

A.8. What conventions for group names (will likely) exist? What motivates them?

Not much, right now -- as we become more public about the use of the directory, 
we'll have to change that.

A.9. Are you (or will you be) using groups in support of messaging applications, 
e.g., email distribution lists?

Not right now, we might, really depends.

A.10. Are you (or will you be) supporting "personal groups", i.e., groups 
created and maintained by ordinary users, or groups designated as "joinable", 
i.e., for which ordinary users can autonomously join or leave? For what 
purposes?

Not yet.

Do such groups occupy the same namespace as other groups or other types of 
objects?

B. Are you (or will you be) tracking "roles"? What does that mean to you?

Yes, hopefully.


Are you (or will you be) implementing something like "role based access 
control"?  If so, how?

See above :)

C. What aspects about your (planned) implementation of groups worries you? What 
group related operations or facilities don't exist that would significantly 
simplify your task if they did?

Lack of on-line data in our organization relating to the org structure that's 
used to create the groups...