Date

Attendees

Friday, October 8th at 10am PT/1pm ET

Join Zoom Meeting
https://zoom.us/j/92440959002?pwd=d1dsRHRZZXpad3FMMUxodVJPejVwZz09


Meeting ID: 924 4095 9002
Passcode: 369672
Dial by your location
Find your local number: https://zoom.us/u/acIvYP0wGe

Goals

Agenda Items - TSC Meeting #3

  1. Call to order: 10am PT/1pm ET
  2. Anti-Trust, Meeting Protocols and Welcome
  3. (Approve Minutes from previous meeting)
  4. Agenda Review
    1. Open Floor: call for New Agenda Items to identify/consider
  5. Second Meeting Agenda:
    1. TSC member introductions (Members)
    2. TSC Charter and Ops overview (Chair)
    3. openIDL overview and TSC resources (Ken Sayers, AAIS – TDOCS and GitHub)
  6. Standing Agenda Items:
    1. TSC efforts and status
      1. Working Groups and POCs
      2. Update on migration project (Ken Sayers, AAIS-- TDOCS and GitHub)
      3. Architecture diagrams (openIDL - Architecture - Tenets and Decisions)
        1. 2021-09-10 TSC Meeting notes--- to reference questions from James Madison 
      4. Progressive stack complexity (Topic from James Madison)
        1. "How much of the full stack listed on the architecture pages is actually needed to get going, to run mid-size, to run at scale.
          1. The three that came up are Cognito, RAM, Elastic Load Balancing.  Could we swap out Cognito for something like IBM APIC, what do we need RAM for, do we need ELB if we care to stay small."
      5. TSC Member Engagement
      6. Other Steering or Board committee updates
      7. Open Floor: Community input/feedback on current efforts
    2. TSC Backlog Planning/Grooming
    3. Upcoming events and TSC schedule
    4. TSC Items to Consider:
    5. Wrap-up: To-dos and community communication
    6. Discussion: time permitting
  7. Adjourn: 11am PT/2pm ET
  8. Extended Discussion/Socialization – Chair will keep meeting open as community requests, for up to 1 hour (12pm PT/3pm ET; minutes not recorded)


Notes:

10:05 Convened

10:06 Minutes approved, motion by Truman, seconded by James, no objections.

10:07 Introductions, including of non-TSC folks

10:09: Ken Sayers updates on core tech:

  • Up and running on AWS, have now left IBM infrastructure.
  • Working with Chainyard to finalize documentation

10:12: Truman updates:

  • Uninsured Motorist RFI for North Dakota, open to input from the community. Similar to COVID19 POC.
  • Regulatory Reporting Governance Committee is getting going
  • Briefings have been done with the anticipated next head of NAIC and others in industry

10:18: Main discussion: getting to production

  • James: Progressive stack complexity. How much of this is needed to get going? How fast can we get a node going if we didn't enable or have to enable some services? E.g. Elastic Load Balancing.
  • Ken: let's work together to find ways to make them optional. These kinds of things will require work with each carrier.
  • David Reale: the smaller the footprint that has to be agreed upon, the better for all of us. We want enough consistency so it doesn't become an operational burden, but we need flexibility. We are hoping to stand up a full node next week on Monday and so this is a live issue.
  • James - where can we engage on something like this? What's the Linux Foundation way?
  • Brian: this is a safe space, let's talk here, and focus it on aspects of public code.Oh, we need to set up a TSC mailing list. That's where this stuff should happen. You can have ad-hoc conversations but let's post decisions or minutes to a public place, the wiki or mailing lists or the like.
  • (general consensus this makes sense). Lots of discussion about how to have more public conversations and change the working norms towards more public processes.
  • Action Item: Brian/openIDL staff to create a technical discussion mailing list specific to the openidl core platform development. For now, use TSC mailing list for any technical discussions.
  • moving on to questions James had posted last time...
  • James: Do we have a bias towards some specific data model, towards denormalization? How general-purpose can we be? What's the balance point? 
    • Truman: this is up to us! We want to grow the community. It all depends on how many different use cases and communities we pull together - auto vs home vs COVID all represent different models and lifecycles
    • Ken: data architecture will be per use-case, they come together at some point in the middle.
    • Brian: harmonization of models will be something TSC and the RR-WG take on, and evolve over time.
    • James: is there a timing on the database question? Which one will we be using? Truman: there likely will be different ones used based on the data model.




TimeItemWhoNotes




Action items

  •  

2 Comments

    • Please see my detailed notes attached to the last meeting minutes for questions we can discuss in this meeting.
    • Would also like to discuss the topic of "progressive stack complexity".  How much of the full stack listed on the architecture pages is actually needed to get going, to run mid-size, to run at scale.  The three that came up are Cognito, RAM, Elastic Load Balancing.  Could we swap out Cognito for something like IBM APIC, what do we need RAM for, do we need ELB if we care to stay small.  
  1. Thank you!  Your notes/questions have been added.