*MACE-Dir Conference Call*
April 30, 2001

*Attendees*

Keith Hazelton (chair) - Wisconsin
Renee Frost - Michigan/Internet2
Tom Fowles - Penn State
Tom Jordan - Wisconsin
John Minor - Wisconsin
Bob Morgan - Washington
Steven Carmody - Brown
Brett Didier - PNNL
David Wasley - UCOP
Ken Klingenstein - Colorado/Internet2
Tom Dopirak - CMU
Ben Chinowsky (scribe) - Internet2

*Discussion*

[AI] Keith will send out instructions on how to use listproc to subscribe to
Internet2 mailing lists.

- groups on the campuses -
Steven: (gives overview of his mail from this morning)
Brown is a good place to start getting a handle on this problem, because as
ugly as the problem may be there, Brown is relatively small and homogeneous,
so the problem is less ugly than at most places. Slice by affiliation and
sub-affiliation, by department (about 150 of these) and affiliation under
that, by course enrollment. Problem is that updates are to be automatic, but
fine-tuning is to be allowed manually, without manual changes being stomped
on by automatic changes. So far no Boolean other than include appears to be
required.
Bob: E.g. exclude? What uses are groups being put to?
Steven: 1) communication channels -- control over who can post to channel,
control over process by which things get posted out the other side of the
channel -- e.g. dean wants to send something to all tenure-track faculty. 2)
around a quarter to a third of people have personal web pages -- want to use
for access control.
Bob: So, email and web access control?
Steven: Yes. Give receivers control if they get channel via email, web
portal, or PDA. Channel is generalization of email list. 1-1 relationship
between a channel and a group in the directory.
Keith: We're following I2-MI standard operating procedure -- when you don't
know what to do, back off and generate scenarios, which in turn can be used
to generate requirements.
Bob: We just went through figuring out how to maintain lists of members of
groups in our computing organization (CAC). For years a person has tracked
the lists and rolled them up into an all-CAC group; this became
controversial when used for web access control. People reacted differently
to web access control than to email -- OK to just keep them off the list if
they don't want the departmental email, but the web info seems to be felt to
be more sensitive. I argued that it's the same info, just push or pull; this
appears to have been successful, for the time being anyway.
Steven: Right, people view them differently, moving closer together though.
Also, often people want to get info for lists for groups they're not members
of -- e.g. deans want to get stuff for undergrads. Need to move people
toward seeing push/pull as "all communications", so if you get it one way
you'll get it all ways.
Keith: One way to guarantee deadlock is trying to define people as "what
they really are" -- must try to get more opinions on all this in order to
stay sane.
Steven: One reason I'm trying to generalize to "all communications" is that
there are two models for ACLs: 1) all readable unless you do something; 2)
every file has its own permissions, and you have a lot of people maintaining
them. It's very important to stay away from 2). The one place I've given
ground is in departments -- based on affiliation -- a department may want to
send some stuff to everyone in the department, some to e.g. only full-timers
in the department -- seems to work OK. I fear that once you start creating
application-specific groups, there'll be no turning back and it'll be a
nightmare.
Bob [mostly joking]: Make groups cost money.
Keith: Or distribute group administration...but that creates problems too.
Steven: Do other people have other ways of approaching this?
Renee: [AI] Renee will put Steven in touch with people working on groups at
Michigan, and will look for more material for groups scenarios.
Tom J.: Two kinds of requests for group info: 1) nebulous - "we need to know
how to group people in the directory"; 2) really precise specs -- e.g. for
calendaring -- specified by how the particular app wants it done
Renee: At Michigan, two ways: centralized (e.g. for class lists) and
creating your own.
Keith: The latter is the Frank Grewe approach...
Steven: We haven't gotten to LDAP for white pages or groups; we do groups
with locally developed software. The useful thing about our software is
"self-exclude" -- members of a group can remove themselves without having
any other privileges for group maintenance. There are some groups that we
insist people sign up for, others where people can pull themselves out for
e.g. junk mail avoidance.
Keith: So, requirements we've added to those set out in your mail message:
removal per Steven, self-creation per Renee, automatic adding and removing
of people from groups.
Renee: Ties in to earlier discussions of whether or not you can update...
Keith: One other big class of uses, mostly in the future: roles. Not about
communication, but about being able to do things. NIST folks working on
role-based access control (RBAC) -- if you look at that work, it gets hairy
as fast as the other stuff we're talking about. Almost every product comes
with its own way of doing this, its own workflow -- will probably get more
demanding as time goes by. Any thoughts on requirements to help us evaluate
different solutions?
Steven: It would be good if we could hear from 6 or so schools, e.g.
Minnesota and Clemson. My guess is that there aren't many sites neck-deep in
this stuff yet -- 6 schools with a couple years experience each should be
enough to extract best practices -- any chance of contacting these schools
over the next week for short writeups?
Bob: MIT also. I asked how MIT was going to do groups -- Paul took umbrage
at the suggestion that MIT's group system wouldn't be used. Learning
management system discussion at U. of Washington...
Keith: [AI] Keith will contact Paul Hill (MIT), Tom Barton (Memphis), Todd
Piket (MTU), Frank Grewe (UMN), and any other likely prospects, and ask them
to provide writeups of their schools' experience with groups.
Steven: [AI] Steven will check the Michigan LDAP list for possible sources
of writeups of experience with groups; he will also check with Michael to
find DoDHE participants who could provide such writeups.
Keith: [AI] Keith will put the RBAC material he has into requirements form.
Tom J.: Is there a reference implementation of RBAC anywhere?
Bob: Role Control Center has been implemented -- apparently not freely
available -- [AI] Tom J. and Keith will draft mail to Dave [last name?] re
getting Role Control Center made available to MACE-Dir.

- Grid directories work -
Brett: We thought about using groups for some stuff -- much smaller but lots
of them and potentially dynamic also. Back end for electronic notebooks. [?]
...
Brett: Keith, have you had a chance to review the notes I sent you re
eduPerson and GridPerson?
Keith: [AI] Keith will review Brett's notes on eduPerson-GridPerson
interoperation, and will make this the first item on the agenda for the next
MACE-Dir call. I'll try to review and get some thoughts out to the list
before then...uhh, I'll be in Turkey...
Ken: Maybe push off to 4 weeks from now -- also the larger Grid/Internet2
issue is under consideration so may want to consider that then...
Keith: [AI] Keith, who will be in Turkey in two weeks, will find someone
else to chair the next MACE-Dir call.
Ken: eduPerson/GridPerson is a pretty big issue all by itself, we should
stay focused on that.
Keith: One issue is "the dreaded linking identifiers" -- we need some way to
identify individuals across two distinct directory implementations -- raises
privacy concerns.
Steven: How would you describe the requirements there? E.g., Brett puts
Keith in PNNL directory, and rather than maintaining his information there,
wants to point at eduPerson directory at Wisconsin. What kind of linking?
Just mapped, or dynamic so that when Wisconsin changes, PNNL also changes?
Brett: No experience with that kind of linking, but my understanding is that
it's very expensive
Tom J.: Replicating attributes, or distributing objects across different
directories? Haven't heard of that being possible.
Bob: this is exactly the sort of conversation we have here when we talk
about apps being directory-reliant...looking in directory rather than
app...need to define caching properly. Can be copied via out-of-band updates
or lookups as you need them...
Keith: So, Tom, I'm willing to be agnostic about weekly update vs. grabbing
bits as needed.
Tom J.: Not startled by the possibility, but by it sounding like it was
already being done.
Keith: No, not being done yet...but a way to coordinate bits is definitely
needed.
Anon.: What tools have been built using eduPerson?
Ken: None yet; Shibboleth is heading that way. I don't have a good handle on
which tool for which purpose and what can be extended to inter-realm use.
Coordinating Grid directories and campus directories is the issue.
Keith: Right, let's start with what we want to accomplish in doing this.
Ken: Also "what basic categories need to exist in campus directories to
enable Grid computing" -- e.g. creating object classes per Kesselman --
separate issue from what you're talking about. One of the ways of storing
intermediate values in a Grid computation is for process to create new
object classes -- Brett?
Brett: Wouldn't surprise me, but I don't know of this.
Steven: At Marlboro meeting it seemed like there was lots of exploration of
filesystem-like uses for directories.
Keith: Tuecke also...taking LDAP a lot further than I've been thinking of.
Anon.: Went with OpenLDAP.
Keith: LDAP as access protocol.
Ken: So, a third thing is specifying DIT for things other than people --
Grid may have gotten further than us with this.
Brett: I'd say that's where most of the Grid directories work has been.
Ken: How much of that has dealt with desktop management stuff?
Keith: CIM etc.
Brett: I don't know -- software stuff was RIB [?] work at
Tennessee...computational resources and software are the two main things
being worked on in Grid right now. [AI] Brett will send out sources of
information on Grid directories work. DOE Science Grid will help Grid
address some of these problems across institutional boundaries, which to my
knowledge really isn't happening yet.
Keith: Is Mike Helm interested in joining these calls?
Brett: Yes.
Keith: Let's try to get an agenda for next time that'll cause him to see
danger in not participating.
Ken: Notes to web site?
Ben: [AI] Ben will set up a MACE-Dir web page, start posting the conference
call notes, and start sending the action items out by one week after each
call.

*Action Items*

[AI] Keith will send out instructions on how to use listproc to subscribe to
Internet2 mailing lists.
[AI] Renee will put Steven in touch with people working on groups at
Michigan, and will look for more material for groups scenarios.
[AI] Keith will contact Paul Hill (MIT), Tom Barton (Memphis), Todd Piket
(MTU), Frank Grewe (UMN), and any other likely prospects, and ask them to
provide writeups of their schools' experience with groups.
[AI] Steven will check the Michigan LDAP list for possible sources of
writeups of experience with groups; he will also check with Michael to find
DoDHE participants who could provide such writeups.
[AI] Keith will put the RBAC material he has into requirements form.
[AI] Tom J. and Keith will draft mail to Dave [last name?] re getting Role
Control Center made available to MACE-Dir.
[AI] Keith will review Brett's notes on eduPerson-GridPerson interoperation,
and will make this the first item on the agenda for the next MACE-Dir call.
[AI] Keith, who will be in Turkey in two weeks, will find someone else to
chair the next MACE-Dir call.
[AI] Brett will send out sources of information on Grid directories work.
[AI] Ben will set up a MACE-Dir web page, start posting the conference call
notes, and start sending the action items out by one week after each call.