*MACE-Dir Conference Call* September 17, 2001 *Attendees* Keith Hazelton (chair) - Wisconsin Renee Frost - Michigan/Internet2 Ellen Vaughan - Internet2 Tom Barton - Memphis Todd Piket - MTU Tom Dopirak - CMU David Wasley - UCOP Steven Carmody - Brown Bob Morgan - Washington Michael Gettes - Georgetown Ben Chinowsky (scribe) - Internet2 *Discussion* - affiliated directories - Keith: the affiliated directories area of work is about linking up information that's spread across various directories -- we should take the standard scenarios-requirements-solutions approach to this. one clear scenario is VidMid work -- could someone close to that effort outline it? Michael: various attributes that need to be stored in some database, many now think a directory is the right place, question then becomes *which* directory. - if the enterprise directory, there are questions about getting the right access, update, and indexing policies. there are already a lot of requirements and best practices for enterprise directories - if not the enterprise directory, do we have one big video directory, or a separate directory for each video application? - how to link enterprise directory with other directories? may need to do some development to solve this problem David: what you're describing seems like a horizontal extension -- more fields for existing entities. There's also the question of vertical extension -- adding entities that aren't in the enterprise directory Bob: a traditional directories person would say that's merely delegating a subtree to a different directory Michael: yes, from a purely technical perspective -- but is that appropriate given how data is being managed? Steven: as we move away from seeing directories as pure repositories and toward seeing them as involving policy, policies could give external users more information Keith: what directory policies correspond to given cert policies? this should go on the list of questions for the MACE-Dir Advisory Board. my thinking is that for now we should focus on the horizontal extensions. other scenarios beside video? Steven: Grid -- community X wants to use grid resource Y -- lots of the people involved are in a campus directory somewhere Michael: Grid, Community of Science, video are all the same problem in the broadest sense Keith: yes, but need to have list to keep coming back to in order to know how far the commonality goes Tom B.: what is purpose? extend white pages browsing functionality so I can follow links to what I want? Keith: that's part of it -- some of the video-specific things are being used to configure video setup -- generally, a way to not replicate information in enterprise directory Michael: what use video would make of enterprise directory depends on meetings to take place at the Internet2 Member Meeting and a visit I may make to North Carolina Tom B.: more general problem? Bob: many apps, each manages context for objects of interest to it, we know it's unscalable to manage all those contexts independently and that they are in fact interdependent, want to provide tools for managing that situation, directories are the tool of choice for that. want to not have to copy all stuff over from enterprise directory space, though not all agree on that Tom B.: so, neither a) put everything in the enterprise directory, because of policy issues, nor b) copy locally, because of the metadirectory problem and the load on the net, but c) connect appropriately Keith: right Michael: we also need to get people thinking about making apps into better net citizens -- getting apps to do the right things with directories, wherever the directories are -- then ask the questions about directories Steven: may need to keep information in a separate directory for policy reasons -- it may be that only some people can see information in e.g. the Internet2 directory, so Brown can't just copy and publish it Michael: the problem of apps doing the right things with directories is independent of the affiliated directories problem. need to address affiliated-directories issues even when e.g. plugging in Corporate Time Keith: agreed. any other scenarios? Ken: Grid is a big one. they don't seem to understand what the campus component of their directory needs is Bob: my email client address book is a local directory maintained by accesses to many remote directories -- process is much weaker than it could be; I don't find out about people's information changing Ken: so, personal directories are another category Bob: may be only a convenience issue for now, but with certs it may become of much greater interest Tom B.: 4 factors: policy, performance, data management, organizational alignment/abilities to execute Keith: I can't think of an issue that doesn't fit under any of those headings Ken: In NMI there's the question "is anybody gonna get to write software besides Globus?" The answer is yes; if we do something enabling H.323, we'll be well regarded. Two related sessions are scheduled for the Member Meeting -- Albert School and Tyler Johnson will present their draft schema, and there's a video-on-demand BoF with Jim DeRoest. we want an aggressive timeframe -- Tyler said he's going to demo something Michael: Nadine and others that were on my conference call with Tyler say they already have some basic directory software developed, and apps to make use of it -- hoping to demo in Austin, yes Keith: will we want to keep things in the enterprise directory? Ken: I don't think so, more information on where to find people to resolve problems. we need to find people in DoE and NASA and NIH so we can understand their requirements -- on the science side, there's the possibility of using directories to simplify access control for e.g. objects on spacecraft; on the administrative side, would like to have good email and landmail addresses. [AI] Ken will ask Alan Blatecky for contacts at DoE, NASA, and NIH who can help MACE-Dir understand these agencies' directory requirements. Tom B.: sounds like data management -- Bob's personal-directories issue with a twist Bob: there's a slippery slope here that leads to considering why data is where it is and how to move it -- "not a problem we can solve in the next month or two." trying to provide some common patterns, but they obviously won't apply to everything Tom B.: "scenario zero" is avoiding people wasting time by querying one directory to get the information they need to manually update another Keith: we have a good list of scenarios, enough to provoke others to say "ah, but you forgot X", so let's move on. I'm obsessed with the shared-identifier issue -- in metadirectory terms, the join function -- but let's save that for another call. All please look for similar deep issues beneath the surface of these scenarios Ken: something similar called "authority files" came up at the U. of Washington School of Information talk on Friday Anon.: the issue with libraries is that there's a large number of very well known names Steven: the authority file is the Library of Congress catalog book Bob: every identifier has some identifying information, so you can distinguish the 35 Mary Smiths Keith: we're not the first ones to think about this David: should affiliated-directory linkages be one-way or two-way? e.g. could I start with the campus directory and say "I think this person is in CoS, get further info from CoS?" Bob: yes, we're talking about what people want in the real world Michael: not hard to do in one directory once solved in the other David: OK. people could put in their own information and link it in a la finger Bob: sounds like the Web David: yes, but with a different access protocol - Advisory Board - Bob: a group was convened at the August IETF, and "a rousing session was had." A list has been set up; a few more people are still needed Michael: could you send the list of current and proposed members to MACE-Dir? Bob: [AI] Bob will see that a list of current and proposed members of the MACE-Dir Advisory Board is sent to MACE-Dir. Keith: I haven't seen an email list Renee: [AI] Renee will send Keith information about the MACE-Dir Advisory Board mailing list. Bob: questions on work we're doing might be dropped over the wall Keith: whose job is it to manage the Advisory Board? Bob: yours Ken: could you plan a meeting at the Salt Lake City IETF? Keith: [AI] Keith will organize a meeting of the MACE-Dir Advisory Board at the Salt Lake City IETF. Keith: I'd like to see Kim Cameron added to the list -- he's willing -- anyone know him? (silence) Keith: any objections or questions on Kim joining? (silence) - eduOrg - David: the draft I sent is off the top of my head Michael: should approach as with eduPerson, useful extensions to existing object classes Keith: I agree. David is saying here's what we need; others -- e.g. Michael and I -- can sort them into things we already have and things we need to create Michael: agreed Ken: where do I find established object classes? Keith/Bob: X.520 and X.521 -- one is object classes, the other is attributes Tom B.: RFC 2256 for e.g. inetOrgPerson Ken: is there a global registry for object classes? Bob: it's been tried, not likely to happen. outside the IETF purview, there's no standard place to register anything Michael: so, we're already creating our own little de facto registry for our community Anon.: aren't OIDs for a global registry? Bob: they're "a global registry of things" Ken: the more we can discuss this before presenting it, the more people will understand the emerging edu* pattern Keith: most of the entries in David's draft I'd be "perfectly happy to see in a white pages" David: Campus Ph is for backward compatibility. URI vs. URL... Michael: some of the things you've listed here raise the question of whether to put this in another directory or make it accessible via a web page David: I don't know, but every campus has its unique way of organizing its web pages -- this is intended to be algorithmically queryable Michael: any apps in mind? David: no Michael: so, this falls under the heading of "it would be nice if..."? David: yes Keith: per Michael, let's define some principle for keeping things minimal the first time around, as with eduPerson 1.0. The things it would be good to know about an organization include how it works with the directory of directories -- this is more apps-specific. Michael, do you want DoDHE stuff here? Michael: no -- until we solve the affiliated-directories problem, the information that DoDHE needs, needs to be kept in DoDHE Keith: add to scenarios: we may need something like this for DoDHE, want to look at more generally for other apps Michael: need to follow eduPerson-like process for eduOrg Tom B.: do we want to enable browsing of an organization's structure? Will an organization have one eduOrg record, or a whole slew of them? David: a whole slew of them, but it's possible to go too far with that Steven: at Brown there are criteria for becoming an official student organization -- could use eduOrg to provide directory-based information for these organizations, allow each to manage its own information. I'm a little uncomfortable with linking to org charts -- campuses are more spaghetti structured than hierarchically structured Keith: person object class had e.g. inetOrgPerson added -- lack of similar extensions for ou suggests that it's less used Steven: what kinds of apps might have had the need to extend ou? maybe workflow apps? Keith: that's an interesting question for us to look into. *Action Items* [AI] 17-September - Ken will ask Alan Blatecky for contacts at DoE, NASA, and NIH who can help MACE-Dir understand these agencies' directory requirements. [AI] 17-September - Bob will see that a list of current and proposed members of the MACE-Dir Advisory Board is sent to MACE-Dir. [AI] 17-September - Renee will send Keith information about the MACE-Dir Advisory Board mailing list. [AI] 17-September - Keith will organize a meeting of the MACE-Dir Advisory Board at the Salt Lake City IETF. [AI] 20-August - Tom Barton will notify the list when the groups-practices survey transcripts are posted to the MACE-Dir-Groups web site. [AI] 23-July - All will send questions for the MACE-Dir Advisory Board to Ben, who will maintain a list of such questions on the MACE-Dir web site. [AI] 23-July - Keith, hopefully with help from Bob Morgan, Ken, and others, will draft a MACE-Dir Advisory Board charter based on David Chadwick's suggestions. [AI] 23-July - David, Michael, and Tom Barton will start a MACE-Dir list discussion of affiliated-directories issues. [AI] 9-July - Steven will send the list a reference to Beth Hale's work on directories vs. databases. [AI] 25-June - Michael will write up a one-page summary detailing the challenges he is facing in creating DoDHE and documenting the interesting solutions he has already reached, such as caching improvisation and browser caveats. Ken plans to use this document to demonstrate the difficulty and usefulness of inter-realm work. [AI] 25-June - Michael will develop an appropriate disclaimer for the DoDHE splash page; he will likely be asking the group for help with this task.