*MACE-Dir Conference Call* August 20, 2001 *Attendees* Tom Barton (acting chair) - Memphis Keith Hazelton (chair) - Wisconsin Lisa Hogeboom - Internet2 Scott Cantor - OSU Steven Carmody - Brown David Wasley - UCOP Renee Frost - Michigan/Internet2 Michael Gettes - Georgetown Ken Klingenstein - Colorado/Internet2 Ben Chinowsky (scribe) - Internet2 *Discussion* Tom: this call will combine MACE-Dir and MACE-Dir-Groups - groups-practices survey - Tom: so far we have 5 email responses and a preliminary transcript of the first survey Lisa: 2 more need to be transcribed, 3 more surveys coming this week Tom: plan to put raw transcripts on Web, with summary Keith: notify list when you post Tom: [AI] Tom Barton will notify the list when the groups-practices survey transcripts are posted to the MACE-Dir-Groups web site. - open-ended groups discussions - Tom: Ellen and Lisa are scheduling now Lisa: we're just starting to get replies -- things are slow in August Tom: suggestions for structure of these more open-ended calls? Keith: I'm thinking about how to address stitched directories -- let conversation take its own course, but have questions in mind in the unlikely event that it falters Michael: ask if they're a good idea rather than how to implement them Ken: asking *where* to use them might be a good idea Michael: ditto Tom: duly noted. might also want to pick up questions, learn what didn't work from groups survey, which will happen first. [AI] Tom Barton will analyze the results of the groups-practices surveys for lessons on what did and didn't work, for use in conducting the open-ended groups discussions. Keith: I'd like to see transcripts of the groups survey before the Keith/Michael/Tom call on the open-ended groups discussions Tom: [AI] Tom Barton will get transcripts of the groups-practices surveys to Keith before the Keith/Michael/Tom call on the open-ended groups discussions. (...survey results for presentation at the Fall Internet2 Member Meeting are not expected to be ready until just before the meeting...) - community-of-interest approach to eduPerson affiliation values - Keith: Tom and I have discussed -- the driver we see is to enable self-selected communities of interest to extend values for EPA. Problem is, what if two communities of interest come up with the same value? So, offer 3 choices: 1) offer eduPerson choices only 2) OID-based approach, defining either "unique-ifier" or the whole thing 3) XML namespaces -- I think this is going to become increasingly popular This is only a straw-man proposal -- advantage is that none of the 3 clash with any of the others -- enable competition among 3 choices, see which prevails Tom: applications of EPA are going to be equality comparisons only, so we don't really care about structure as long as unique. these are community-based -- natural extension to 1.0 Ken: I can see two kinds of community of interest -- e.g., physicists' affiliations in "rarefied" areas of the enterprise directory, vs. e.g. at Colorado with each campus developing its own directory space, needing to know things like "emeritus". where enterprises have need for this, vs. where community of interest has interest Steven: issue of what affiliation is vs. who's saying so. campuses are going to need more granularity, but I'm worried about diluting the core value of the existing values -- for licensed information vendors, for instance -- by adding things like "emeritus". Ken: interesting issue -- the more refinement we have in the core values, the closer we get to data administration issues Keith: Chadwick suggests promoting two values out of eduPerson into X.521 -- to be discussed later in this call. Do we have a principle that determines what belongs in eduPerson and what doesn't? For instance, should physics information go in eduPerson, or should there be a physicsPerson for that? Steven: could be done either way, but we should decide, and encourage consistency Ken: we can't hide behind OIDs in hopes of getting consistent naming -- most of these communities won't have a clue Keith: Michael, do you want MACE-Dir to be the gatekeeper for people putting stuff in? Michael: most people have a good idea about things local to their institution, but once we start looking at communities, we're more likely to find things that are globally interesting. I agree with your concern, but we may lose valuable information by not addressing this Keith: on the other hand, we could become a bottleneck Michael: we want to be able to see patterns of how best to handle this as those patterns emerge, then go back to the communities of interest with that information. Tom: a registration authority? Michael: yes, but for the first year we track what's being done, how, and why, and see what we can learn -- e.g. the call we want to have with Tyler Johnson re H.323...I don't think we're preventing people from moving forward -- usually there's a month or two between registration and implementation, so we'd have a chance to intervene Ken: when I first heard about the OIDs registry, I thought it was a joke Tom, Michael: just a unique-ifying prefix, no navigation, use existing OIDs registry ... Michael: we'd be passive, sitting back and looking at trends Tom: at least two things are being discussed here: original proposal of how to expand list of EPA values, and registering new attributes Steven: I vote for having people notify us whenever they start using values in EPA that aren't in the core set. Per Michael, values come from us learning about how people find use in them Tom: but that causes risk of collisions Michael: right, we did agree that restricted-value items in eduPerson wouldn't be extensible at local level Steven: people would register a namespace prefix with us Keith: right, we offer widely disseminated namespace, at cost of having to register your unique-ifier with us Steven: otherwise, if a school needs its own values in this attribute, it has to cut a deal with a vendor Keith: this isn't willy-nilly, it's controlled Michael: I disagree -- schools would end up populating with their own stuff, but saying that they're eduPerson-compliant ... Scott: this is the question of the best way to create an extensible data model in LDAP Michael: eduPerson is trying to be specific about how the values get used -- if we lose that, we're losing something fundamentally valuable in eduPerson Keith: want to be easily extensible, not mess with use of attribute, ensure uniqueness -- Michael, how do you think we should do this? Tom: there has to be a registration function to ensure that values that people add don't later become illegal Michael: but can do... Tom: [completing Michael's thought] "backward analysis?" Michael: right Tom: good point Keith: I thought we were closest to consensus when we were talking about a lightweight registration process -- it's when we started to think about putting conditions on registration that the consensus started to unravel. 3 conditions: expanding EPA, unique-ifying prefixes, lightweight registration process that keeps us in the loop but doesn't slow down people who want to expand vocabulary Michael: only attribute values should be those officially blessed by eduPerson, each has an OID... Keith: then communities can't name their own values, at least the prefix part of them Tom: I'm confused on Michael's position... Michael: I don't want to get in the way of people using whatever they like *in their own attributes*, but I don't want them to be able to put whatever they like in EPA... (...agreement to restrict discussion to EPA for now...) Keith: 1) scope is list of permitted values for EPA, 2) OIDs, 3) lightweight registration process -- consensus? Michael: I think I agree, but if scope is EPA only, I'm concerned. If we can get them to register all their stuff, it will encourage them to see what's going on in the rest of the world, and give us a chance to feed back to them. Keith: I'm happy to expand discussion to other attributes on another call Ken: attributes vs. object classes? ... Tom: I'm lost Keith: we went from one attribute to several -- Ken is taking next step of us being responsive to people who want to suggest entire new object classes Tom: e.g., we might want to make sure attribute names don't clash Keith: like a "bridge schema authority" -- I don't know if we want to go that far Steven: e.g., discussions with Grid people Tom: could have an "Alvestrand-esque" site where people can register this stuff Steven: possible division between NSF-funded task, which would be more like what Ken has just suggested, and MACE-Dir, which would be more narrowly concerned with eduPerson Michael: if this schema thing is going to be successful, we need at least a half-timer to deal with it Steven: maybe, but it's a ways off, and we can apply all we've learned about "minimizing the number of in-boxes things have to pass through" Michael: forgive me for being skeptical - EPPN - Steven: if an attribute is stored in a directory, what implication, if any, does that have for the origin of the attribute? organization is asserting that attribute-value pairs are correct and relevant to this individual ... Keith: the radically-simplifying approach we need for Shib is that departments will define in ways that make the most sense to them, and eduPerson will catch up later. I have a notion of who is asserting. "general-purpose enterprise directory" -- assumption is that asserting entity in that directory is the institution -- also the issue of how you ensure that it's that directory you're talking to ... Michael: need same notion of Club Shib -- a registry of things that are trusted, with the directory perhaps among them. Keith: right Scott: algorithmically, how in querying a directory is an attribute authority to determine scope or context of the values it's passing back? ... Keith: throw away the at sign, replace with a period, treat entire EPPN as a unique-ifier Michael: OK, but at least for the short term, why can't we say the attribute authority is enterprise-representative? at a conceptual level, is it OK for Shib to look at things that way? Scott: yes. ... Keith: maybe call it something different but note that it was derived from EPPN Michael: don't come up with another attribute at this point Keith: it's not, it's just a label. Let Shib folks proceed and call it "munged EPPN" or whatever. (apparent general agreement) *Action Items* [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] 20-August - Tom Barton will analyze the results of the groups-practices surveys for lessons on what did and didn't work, for use in conducting the open-ended groups discussions. [AI] 20-August - Tom Barton will get transcripts of the groups-practices surveys to Keith before the Keith/Michael/Tom call on the open-ended groups discussions. [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.