Group Practices Survey
Todd Piket, Michigan Technological University 
Fall 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?

 Static, i.e., a group object is instantiated with an attribute
listing the (person or other) objects which are members.

	We use this because they tend to respond faster for our current 
applications.

 Dynamic, i.e., defined by evaluating an ldap URL. A group object may,
but need not, exist.

	Using Dynamic is probably inevitable, especially for email list 
generation.  I would like to avoid using Dynamic when possible, however.

 Dynamic forward reference, a special case of dynamic representation
in which an object's group memberships are listed as the values of an
attribute designated for that purpose.

 Spatial, another special case of dynamic representation in which
group membership is inferred from location in the DIT.


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 a groupOfUniqueNames and would be opposed to breaking from 
current schema standards.

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

Will not use.

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

There will be some automated processes for as many "institution level" groups 
that can be determined as useful.  Many will be maintained by hand using web 
based tools developed locally.


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

	Yes.

How?

	iPlanet directory server will maintain referential integrity.


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

	Yes, there are groups of groups.  Only people will be members of groups

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

Probably inclusive - we would need to write a plugin.  But, it will not happen 
right away.

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?

No

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

There is not a policy yet.  There will be a super user set to administer all 
groups.

Is administration of groups (to be) delegated? 

Yes, because of the policy that will be written.

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

	Not an issue 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?

Currently there is no privacy for groups.  Before this question I hadn't really 
thought of that before, so I have no idea yet.  It seems reasonable for a policy 
to exist for this sort of thing.

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

Will not be conventions right away.


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

	Yes, we will be using groups in support of email distributions.

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? 

Yes, in the future, for study groups, student organizations, and web based 
storage data bases.

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

Yes, they will.

B. Are you (or will you be) tracking "roles"? What does that mean to
you?  Are you (or will you be) implementing something like "role based access
control"?  If so, how?

Not yet, but perhaps in the future.

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?

	It would helpful to have tools already written that maintain groups.  At 
least some tools that perform basic group operations, determine who has what 
groups and allow that person to modify, add, and delete members accordingly.

D. Please list any further current or planned applications using
middleware groups that haven't already been discussed and provide a
brief description of each.
E. Thanks for sharing that information. In addition, we'd appreciate
your direct advice on the direction MACE-Dir ought to take in this area.

Writing a set of tools that are generic and delegate administration on the web.