Time

Agenda Item

Lead

Notes

5 min

• Start recording

• Welcome & antitrust notice

• Introduction of new members

• Agenda review

Chairs

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.

• New Members: 

  • @Eric Drury

10 mins

Review updates to the draft spec

@Drummond Reed

• See the opening sections of the ToIP Trust Registry Protocol Specification (Google doc)

• All content from the corresponding wiki page has been moved over

• Conceptual diagrams need to be added

10 mins

Discuss next steps with the spec

Chairs

• Finishing the Requirements section

• Review Scope section

• How should the Protocol be defined?

  • Answer: text description pointing to Appendix A.

• Where does the API specification section go?

  • Answer: Appendix A.

10 mins

History requirement

@Darrell O'Donnell

• Darrell did some thinking about the discussion from last week's call about the possible requirement for the history of a particular entry in a TR

• He is worried that the complexity of the API increases tremendously

• We discussed what would be in scope for a history parameter — whether it was just a history of entries or whether it would include other information, including query history or full transaction history, then

• If it is a timestamped series of entries about the status of a particular entry, then it is a much more limited requirement that is much more feasible to include in V1

• @Jim StClair pointed out that many governing authorities will have a requirement for audit logs that can be used for conformance.

• @Drummond Reed suggested we take a "simple as possible but no simpler" approach to not include any feature that is not a "must have" for V1 — but that we document that decision in the Scope section and then see what the feedback is in the community review and public review stages.

• @John Walker shared that he can see the need for the history feature in the future, but that he did not believe it was going to be a requirement for GCCN participants at this time.

• DECISION: The history parameter will out of scope for V1 but will be documented in the Scope section as a candidate for future versions.

10 mins

Assignments for the next meeting

Chairs

• @Drummond Reed proposed that we go through the spec to assign all the action items left to complete an Implementers Draft.

• DECISION: We will take one more week to finish the current spec before transitioning it to become the Implementers Draft and starting to seek detailed review from implementers.

• FRONT MATTER SECTIONS

  • ACTION: @Drummond Reedto review all front matter sections to ensure they are ready for an Implementers Draft.

• REQUIREMENTS

  • ACTION: @Darrell O'Donnell and @Drummond Reed to review notes and either add additional requirements or remove the notes by next week's meeting.

• SCOPE

  • ACTION: @Darrell O'Donnell and @Drummond Reed to capture any other scope decisions in this section.

• DATA MODEL

  • ACTION: @Darrell O'Donnell to propose a textual description of the data model that refers to Appendix A for the normative requirements.

• PROTOCOL

  • ACTION: @Drummond Reed to recommend what text is needed in this section vs. the overall Requirements section.

• Appendix A: OpenAPI Specification

  • The YAML file is normative — @Darrell O'Donnell believes it is ready for the Implementers Draft stage.

  • For the final Working Group Approved Deliverable, we will put a snapshot of the YAML file into the Markdown version of the spec.

  • Until then, we will just put a link into Appendix A.

  • ACTION: @Darrell O'Donnell to complete any other edits to the OpenAPI specification and then add the authoritative links to Appendix A for the Implementer's Draft

5 mins

• Review decisions/action items

• Planning for next meeting 

Chairs

• Goals in the next meeting:

  1. Review the entire spec and resolve any comments, notes, action items, etc. to prepare it for the Implementers Draft stage.

  2. Assign tasks for Task Force members to seek review from their respective communities.