• ACTION: Kevin Griffin and Drummond Reed to arrange a meeting with Judith Fleenor, Darrell O'Donnell, and TSWG Task Force leads to drive to consensus on our GitHub repo management and spec template policies.

• See the first agenda item below.

Kevin Griffin Wenjing Chu Drummond Reed

Kevin reported that he is working on GitHub setup and team management.

The question of what specification template to use is still in discussion. If we intend to use an ISO-friendly template, Kevin can create a repo using that template.

We discussed the pros and cons of that avenue. Note that we (ToIP) remains in control of the specification and future versions.

Judith said she believes there may also be a similar PAS (Publicly Available Specification) process with the IETF.

Viky Manaila pointed out that "ISO acceptance in EU is based on a special agreement", which means that ISO standards are accepted in the EU. So she encouraged that option. She shared the Vienna Agreement between ISO and European Committee for Standardization: https://single-market-economy.ec.europa.eu/single-market/european-standards/standardisation-policy/international-activities_en

Wenjing Chu was in favor of using a format for the specification that will be the final.

ACTION: Judith Fleenor, Drummond Reed and Wenjing Chu (if available) contact Karla McKenna to learn more about the specifics of the ISO PAS process.

Wenjing asked if Kevin's template would produce a publishable document, and he confirmed it would using GitHub pages.

ACTION: Kevin Griffin and Wenjing Chu will work together to set up the TSP spec repo and template.

Wenjing took us through the start of the Working Draft.

We reviewed the overview section (see screenshot #1 below). Wenjing make two recommendations:

1. Break out the TSP Routing specification as a separate document (which depends on the base TSP spec).
2. Break out another future document, tentatively called Trust Spanning Protocol Multi-Party Messages, as part of our future work.

Darrell O'Donnell: "That “Future Work” section can handle the key points we don’t want to lose (e.g. that could paint us into a corner and block multicast)."

Antti Kettunen asked: So do we need to create a clear ‘protocol capabilities’ section that would enlist what will be available at some point of the roadmap?

Wenjing said that was a good suggestion, but would probably work best in a Future Work session.

Samuel Smith pointed out there are multiple facets of a multi-party messaging protocol, such as group list management, so it may actually make for more than one specification (or for a more complex specification). Wenjing agreed.

Neil Thomson: "Grouped Unicast -> Future "stuff".

DECISION: We will include a basic multicast protocol spec in our list of additional specifications, but reference a more complex group list management multicast spec as Future Work.

We reviewed the core diagram (see screenshot #2 below).

Neil Thomson asked: "Any particular reason that support system/endpoint system arrows are unidirectional?"

Wenjing agreed that was a good point — it is just a conceptual relationship with supporting systems. So he will remove the arrows.