CTAB Call Wed. Aug 1, 2018
CTAB Call Wed. Aug. 1, 2018
- Brett Bieber, University of Nebraska (chair)
- Mary Catherine Martinez, InnoSoft (vice chair)
- David Bantz, University of Alaska
- Tom Barton, University Chicago and Internet2
- Chris Hable, University of Michigan
- Ted Hanss, University of Michigan
- Jon Miner, University of Wisc - Madison
- Joanna Rojas, Duke
- Chris Whalen, National Institutes of Health (NIAID)
- Ann West, Internet2
New Action item
[AI] (Brett) create draft of the options for implementing a “hard metadata validation” as part of taking BE Implementation to the next level.
Baseline Expectations Tabletop Exercise #2 on dispute resolution was held Monday, July 22, 2018
- There was a productive exercise and discussion on the tabletop exercise call.
- The group clarified steps when a concern is raised:
- "Bob" sends email to InCommon Operations complaining about an IDP
- Stage 1 is for the complainant ("Bob") to reach out directly to participant to try to resolve the issue.
- There was discussion of a scenario where Bob does not want to take the matter forward after he contacts the IDP.
- In this case, it's possible that InCommon Ops will decide to notify CTAB of the issue
- Note: we should modify the maintenance process doc to state that InCommon can be the complainant if community member (Bob) does not want to take issue forward.
- Original “Concerned Party” (Bob) need not be the only party that can take the concern they raised on to Stage 3. Stages 1,2, and 3 are defined in maintenance process doc
- On the question of how CTAB should make the decision on whether to take a matter forward to Stage 3, after it’s been referred to CTAB by InCommon --- should CTAB vote, should a consensus process be used? The decision was to wait until this matter should arise, if it does. Probably to CTAB would use consensus
- Decision was to drop the Stage 3 “review board” concept in Maintenance Process Doc which was likely overly complex. CTAB can be the review board.
- Also, John Krienke will review the Maintenance Process Doc again with an eye to InCommon staff process.
- Baseline Expectations FAQ https://spaces.at.internet2.edu/x/iYRQBw now has an FAQ item SIRTFI
Community Dispute Resolution Process Notification Template ,
- Brett has drafted a template
- Group agreed Brett's draft is a good notification.
A “good ending scenario” should include a letter to the participants stating that the matter has been resolved.
- Set up another TableTop Exercise session to cover final steps for good ending scenario, bad ending scenario, etc.
- Brett asked Erin to schedule this Tabletop exercise #2.
- scheduled for Monday, Aug 20, 2018
Community Consensus Process doc (updated by Brett)
- Emily will save to PDF and move this to Trust and Identity Doc repository the week of Aug 6, 2018.
- Then Brett will notify the community that review of the community consensus process doc is closed and the final doc is in the repository
- Update: see doc in repository here: http://doi.org/10.26869/TI.107.1
Progress from the field on meeting BE compliance
- David Walker and Renee Shuey are making progress in their outreach around BE.
- One school in California had some issues around the logo
- Background on the logo metadata element are found in BE FAQ https://spaces.at.internet2.edu/x/iYRQBw
- David and Renee will prepare a report on their findings
- Groups/audiences for Baseline Expectations:
- Entites playing attention and responding
- Entities who are making changes but did not respond
- Entities with no changes, no response
Moving to Next Phase of BE
- What should be the date that we want to require BE metadata elements must be in InCommon metadata?
- When we settle on a date, we should inform InCommon Operations team of date.
Issue of soft warning versus hard validation for metadata
- Current there is the metadata health check process. https://www.internet2.edu/blogs/detail/15570
- At this point there is a “soft warning” if metadata elements are missing. The submitter gets a notice of missing metadata elements when they “save” but the entity is still accepted.
- Possible downside to “hard validation” is that we could stop some entities from publishing new entities in InCommon?
- We should give advance warning to the community when we move to “hard validate.”
- Perhaps allow the hard validation to be made soft if an entity provides a reason for their inability to provide complete metadata.
- Could ask InCommon Operations staff if there could be a behind the scenes way to handle exception situations.
- Suggestion to disallow entities from making their metadata worse, such as removing a logo if they had one previously.
- At a certain point, after many reminders about incomplete metadata, send a note to the InCommon Exec for the entity instead of to the admin?
[AI] (Brett) create of draft of the options for implementing a “hard metadata validation” as part of taking BE Implemention to the next level and share it with CTAB for review.
Ann: There are plans for an R&S checkbox to be added to the Federated Manager for IDP.
Tech Ex 2018 in Orlando
- CTAB meeting Wed. morning Oct. 17, 2018, 7:30am - 8:30am
Next CTAB call: Wed. Aug. 15, 2018