Date: Fri, 29 Mar 2024 12:40:17 +0000 (UTC)
Message-ID: <1992730310.7959.1711716017671@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_7958_1863560532.1711716017669"
------=_Part_7958_1863560532.1711716017669
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
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&nb=
sp;
- 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 =E2=80=9Char=
d metadata validation=E2=80=9D as part of taking BE Implementation&nb=
sp;to the next level.
Discussion
Baseline Expectations Tabletop Exercise #2&n=
bsp; on dispute resolution was held Monday, July 22, 2018
https://docs.google.com/docume=
nt/d/1OPS5RG-gomD2PCAnk5Q_CZpdAz-QohJHpD8hbhtP-8w/edit#bookmark=3Did.u1qjgw=
87mr3f
- 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 pa=
rticipant 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 CTA=
B of the issue
-
- Note: we should modify the maintenance process doc to state that &=
nbsp;InCommon can be the complainant if community member (Bob) does not wan=
t to take issue forward.
- Original =E2=80=9CConcerned Party=E2=80=9D (Bob) need not be the only p=
arty that can take the concern they raised on to Stage 3. Stages 1,2,=
and 3 are defined in main=
tenance process doc
- On the question of how CTAB should make the decision on whether to take=
a matter forward to Stage 3, after it=E2=80=99s been referred to CTAB by I=
nCommon --- should CTAB vote, should a consensus process be used?&nbs=
p; The decision was to wait until this matter should arise, if it does. Pro=
bably to CTAB would use consensus
- Decision was to drop the Stage 3 =E2=80=9Creview board=E2=80=9D c=
oncept in Maintenance Process Doc which was likely overly complex. CTAB can be the review board. =
Notification Template:
Community Dispute Resolution Process Notification Template ,
- Brett has drafted a template
- Group agreed Brett's draft is a good notification.
A =E2=80=9Cgood ending scenario=E2=80=9D 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 reposito=
ry the week of Aug 6, 2018.
- Then Brett will notify the community that review of the community conse=
nsus 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 arou=
nd BE.
- One school in California had some issues around the logo
- 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 mu=
st 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 =E2=80=9Csoft warning=E2=80=9D if metadata ele=
ments are missing. The submitter gets a notice of missing metadata el=
ements when they =E2=80=9Csave=E2=80=9D but the entity is still accep=
ted.
- Possible downside to =E2=80=9Chard validation=E2=80=9D 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 =E2=80=
=9Chard validate.=E2=80=9D
- Perhaps allow the hard validation to be made soft if an entity pr=
ovides a reason for their inability to provide complete metadata.
- Could ask InCommon Operations staff if there could be a behind the scen=
es 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, sen=
d 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 =E2=80=9C=
hard metadata validation=E2=80=9D as part of taking BE Implemention t=
o the next level and share it with CTAB for review.
Ann: There are plans for an R&S checkbox to be added to the Federate=
d Manager for IDP.
Tech Ex 2018 in Orlando
Next CTAB call: Wed. Aug. 15, 2018
------=_Part_7958_1863560532.1711716017669--