Conference Call Info: Video Bridge 22102

  1. Dial the Auto Attendant at 812-856-7060
  2. Enter the conference number (22102) followed by the # key (e.g., 22102#)

Attendees

Who

With

Attended

Benn Oshrin

Internet2 / Various

(tick)

Eric Westfall

Indiana U / Kuali

(error)

Jeremy Rosenberg

SFU

(error)

Jessica Coltrin

U of Arizona / Kuali

(tick)

Jimmy Vuccolo

PSU

(error)

Lucas Rockwell

UCSF

(tick)

Renee Shuey

PSU

(tick)

RL "Bob" Morgan

U. Washington / Internet2

(tick)

Steven Carmody

Brown

(error)

Matt Sargent

Indiana U / Kuali

(tick)

Agenda

  1. Introductions/Roll Call
  2. All - Any Updates?
  3. Action Items Updates? (below)
  4. Project Proposal - Eric/Jessica/Renee/Matt
    1. Draft Proposal - Eric/Jessica
    2. Timeline and Estimates Work - Renee/Matt
  5. Strategy Group Updates - Bob

Action Items from last time

  1. follow up with berkely on getting them involved in this group
    1. strategy group will follow up on this
  2. follow up with UofA and bill on seeing if we can get them at the table as well?
    1. if Arizona is in that state, great
    2. if USC is in that state, we could get them involved as well
  3. should socialize with other groups, show them requirements, request that they provide input
  4. bob will continue to do work on the reference architecture

Notes

matt: welcome to the group Lucas

bob: the point is to include UCSF since they are going through an IdM process themselves since there is likely some substantial overlap with what they are going through right now and what we are doing as well.

matt: moving along to the action items.

bob: jessica is here with a rice hat on?

jessica: yes, the Arizona hat is off, working from Rice

bob: yock noted that UofA was interested in matching so we may need someone from that

benn: since our last call the UC groups (Berkley and SF) have had their subgroups meeting and Id Match and the Registry data model are of big interest.  The Id Match one could turn into sort of a joint-venture subgroup work.  We've started a straw man that we might be able to share with this group at the next meeting.

lucas: we've started a group to talk about data models.  comparing UCSF and Berkley to figure out what current models don't allow that we'd like to do.  Things work pretty well, but we don't like the physical registry we have and they are pretty different, part of the issue.  how they differ and how could we do it if we decided to do it all over again.

bob: bill yock had an item to see if UofA has someone to drop into our group

jessica: i know that bill does have a meeting w/someone at UofA

bob: kuali days is coming up.  some I2 folks are heading to an IdM meeting in Europe so that might come up there.

bob: back to the data model, I think the hope is that we can line up with PSU, KIM, etc.  Not an easy task from different origins, but it is something we should look at.  Not sure what the state of the PSU material is in

renee: the model and catalog is available on our dev site and I'll reshare that with this group

bob: great and if there is some specific doc we should look at, we'd be much appreciative.  might be good for the UCSF and Berkley

lucas: we'd like to look at both 

benn: could we put that on the Wiki? 

matt: yes I'll add a section and each can put in their own links and notify the rest of the group via the listserv

bob: i think we've found in the past that we get boxed in by our existing schemes for us that have a long standing registry.  changes are difficult to include or make; in particular as we bring in new populations from different sources that different kind of modeling could be of use.  i'm hoping we can at least, possibly avoid those mistakes with our scheme.

renee: with PSU we use types to try and have different schemes for those types to try and keep us from being locked in

bob: so would that be more object modeling

renee: probably

benn: type is definitely one piece of the puzzle.  extensibility seems to be another important part, common core with easy ability to add unique attributes now and in the future

bob: yes, and as requirements change that'll be a big need.

bob: continuing to poke away at the reference architecture.  seems that part of what i'm considering is what the overall project would need.  Service interfaces, bus enabled, etc.

renee: I wonder how comfortable folks are with the chunking.  with phase 3 and 4 i'm not totally comfortable with how those are laid out, seems like some of the need to be in place for the other functions

benn: i agree in that there is definitely a dependency tree, seems like profiles need to be done earlier.  having provisioning later on doesn't bother me as much, seems like a bolted on type of component.  seems that search/match

renee: i think look at the reqs and grouping things would help with this as well.

benn: setup a quick brain storming call, I'd be happy to join in on that.

bob: seems that you need all or nothing, for assurance it seems that you'd need it be considered from the beginning (data model) since changes related to it later on would be invasive.

benn: i agree that getting the data model correct early on is well worth the effort, but having some working models to reference already will be helpful in our efforts.

bob: i brought up assurance in particular because it's new/hot and no-one is doing it, there's a risk in having it later on

renee: what about KDs?

matt: i have a BoF session

renee: great

jessica: it's on the K board agenda as well.

renne: at Educause there was a session about an evening BoF w/free drinks and it was packed.  ken was saying that what he needed to move forward was the names of who is really interested.  if there is an opportunity to get those names, that'd be great.

bob: i'm sure there'll be more discussion on that in the strategy call today as far as getting more involved.