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.
Thank you! Your notes/questions have been added.