*MACE-Dir Conference Call*
June 10, 2002

*Participants*

Tom Barton -- Memphis (chair)
Rob Banz -- UMBC
Brendan Bellina -- Notre Dame
Mike Grady -- Indiana
Paul Hill -- MIT
Chad La Joie -- Virginia Tech
Dan Malone -- Cal-Poly
Todd Piket -- Michigan Tech
Bob Talda -- Cornell
Ellen Vaughan -- Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

Utilities

	Keith polled the audience attending the directories BoF at the 
annual Internet2 Spring Member Meeting about what directions MACE-Dir 
should look in upcoming projects.  The overwhelming preference of the 
assembled was development of various directory utility tools.  Tom 
drafted for the call a list of several potential utilities the group 
could work to develop.
	RIBot would be a tool to maintain the referential integrity of 
static groups and the proposed isMemberOf attribute.  There are a few 
mechanisms that have been proposed by Michael Gettes of Georgetown as 
well as several members of MACE-TAB; the utility could work on periodic 
LDIF dumps of the directory, which guarantees full referential integrity 
after updates, or it could navigate the dynamic links and static groups 
in real-time through LDAP, and thereby slowly maintain referential 
integrity.  The group decided this may not be the best project to take 
up immediately due to the potentially implementation-specific nature of 
its usefulness as well as the lack of broad deployment of an 
isMemberOf-type attribute.
	An LDAP-analyzer service was another possibility considered by the 
group.  A current version, a model which may be followed in a more 
developed tool, is a web page which asks for the address of an LDAP 
server to be tested.  The tool then proceeds to perform multiple 
capability and performance tests on the directory through a sequence of 
LDAP series.  One developed by the group would primarily test the 
directory for things that would be expected in terms of eduPerson, 
inetOrgPerson, and some concrete recommendations set forth in the LDAP 
Recipe.  This service was deferred as well.

GASP

	Receiving far more support from the group was an application of 
some type for the management of groups, or GASP.  This interactive 
service could run as a privileged user or act as a proxy on behalf of 
the user connecting to it.  One reason to develop this tool is to manage 
isMemberOf directly in person objects without allowing end user 
applications to do it.  There are very significant implications on how 
the tool would be designed whether it were assumed that GASP would be 
the only way in which groups would ever be modified or not.
	The group wanted to develop this tool as a front-end API which 
could be called from within other programs that may want to be able to 
manipulate groups. MACE-Dir would also develop a web-based interface 
that would plug into the API.  There are some interesting questions 
about where and how access control would be performed, especially if 
GASP has its own privileges and does not act as a proxy for the user.  
The back-end API would be simpler and likely rely on standards already 
developed.  LDIF, XML, and live LDAP were three possible approaches 
mentioned by the group, and development of connectors from these 
standards or a simpler API which would then be bridged to these 
standards would be feasible.