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. 

Discussion

Baseline Expectations Tabletop Exercise  #2  on dispute resolution was held Monday, July 22, 2018  

https://docs.google.com/document/d/1OPS5RG-gomD2PCAnk5Q_CZpdAz-QohJHpD8hbhtP-8w/edit#bookmark=id.u1qjgw87mr3f

• 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

Notification Template:

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. 

Next steps: 

• 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

Update the maintenance process doc and the consensus process doc   based on the outcomes from the tabletop discussions

 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
• https://meetings.internet2.edu/2018-technology-exchange/detail/10005252/
  

Next CTAB call: Wed. Aug. 15, 2018