Modified per feedback from 18 July 2001 mace-dir groups subgroup conference call. -- GROUP PRACTICES SOLICITATION We would like to solicit information on current or anticipated practices and issues related to provisioning and using group objects in X.500 or ldap capable directories. An outline is provided below to which you might refer when describing your current and/or planned group practices. The information you provide will be used to help determine the direction mace ought to take with regard to group related middleware matters. A. Please address each of the following items. It would be especially interesting to relate how the nature of any 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, ie, a group object is instantiated with an attribute listing the (person or other) objects which are members. Dynamic, ie, defined by evaluating an ldap URL. A group object may, but need not, exist. 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 object class(es)? If the latter, 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? Do (or will) you maintain referential integrity, i.e., if an object is removed from the directory, are its group memberships also removed? How? A.4. Can group objects be members of groups? What object types can 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)? 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? A.6. What policy pertains (will pertain) to administration of group membership? Is administration of groups (to be) delegated? How is the set of groups (to be) groomed, i.e., stale ones made to go away eventually? A.7. What privacy or security policy pertains (will pertain) to any of your groups? Are there policies that prohibit or inhibit the exsitence of certain types of groups? A.8. What conventions for group names (will likely) exist? What motivates them? A.9. Are you (or will you be) using groups in support of messaging applications, e.g., email distribution lists? 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? 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? Are you (or will you be) implementing something like "role based access control"? If so, how? 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? D. Please list any further current or planned applications using directory 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 ought to take in this area.