Discussion of progress on the working draft of the ToIP Technical Architecture Spec and outstanding issues.
- DECISION: We will deliver a first Public Review Draft by Thursday 8 Sept 2022 in order to present it at the Hyperledger Global Forum in Dublin beginning Sept 12. We will also try to complete the majority of the work of having a complete draft by the end of July so we can work (possibly largely asynchronously) on issues in August.
- Wenjing pointed out that we will need to pick up the pace on the spec if we are going to meet that deadline. This means we'll need to work at resolving the comments that we have first. He doesn't want to add new content if there is not yet agreement over current content.
- Drummond said he intended to lean into editing and issues management in July.
- Vlad Zubenko asked about issues management.
- Wenjing said that we need to start posting more and working through them.
- Allan pointed out that it is not yet a spec that can be directly implemented; it is an architecture spec. So it's important to set the audience and the scope.
- Vladimir Simjanoski felt that a strong scope statement will help us close a bunch of open issues. It will also be very useful as an educational.
- ACTION: Allan Thomson and Drummond Reed to draft an Audience and Scope section that clarifies that the ToIP Technology Architecture Specification is a higher-level architecture spec that is not intended to be detailed enough to write implementation test suites against.
- Wenjing felt this spec can help make it clear what the purpose of the document is in terms of limiting interoperability choices, including guidance to protocol designers.
- Tim Bouma pointed out that four layer models are well established, but we need to get down to more specifics of the boundaries of the layers.
APAC:
- Wenjing Chu has not closed a few of the largest remaining comments because they affect the overall structure and content of the spec.
- SCOPE -
- If we Agree - get it written; If we don't - then what?
- AUDIENCE -
- If we Agree - get it written; If we don't - then what?
- How deep does this go - it's aimed to describe broad cases, the layers and interactions. It does not hold opinions on specific implementations.
- PHILISOPHIC -
- Wenjing used the example of IETF specs. They are often broken into separate documents. One specifies the overall architecture and components. Then separate specifications are written for each protocol or interface between components.
- The architecture spec also lays out terminology and use cases and names the requirements for layers.
- Neil Thomson said the the first group that needs consensus on scope is this TF. We also need consensus on the canonical use cases — and to be specific about what use cases are out of scope.
- Darrell said that this document is more descriptive than prescriptive.
- Neil Thomson : "Defining sufficient details write test suites (which has been asked for) - is clearly out of scope."
- We discussed the detailed diagram contributed by Allan Thomson and agreed that it went to a level of detail that was more appropriate for an interoperability test case specification than for a high-level architecture specification. So we propose to move it to one of the more detailed specs to follow the architecture spec.
- Wenjing said that many of the other comments have to do with discussions of terminology.
- Jo agreed and said that as long as Wenjing was using terminology consistently throughout the spec, he was okay.