- We had general discussion of what should be Use case subcommittee responsibility and the proposed flow/tasks division between a different subcommitees/projects/Release management. We have a separate email thread handling that discussion. Right now, the flow proposal is following:
1. Use case subcommittee discuses new use cases
2. Use case subcommittee produces use case flow diagrams, provides its view on the foreseen modules introductions/modifications and suggests potential PNFs / VNFs
3. Use case subcommittee gets feedback from the potentially effected projects including integration team on feasibility
4. Iterate back to 2.
5. TSC approves the use case
6. In case new modules or new API introduction is foreseen, architecture subcommittee defines the new/modified ONAP flows and the interfaces principles, based on the approved use cases
7. Projects define their extended functionality and their external APIs, following those principles.
8. Detailed per-component flows are defined and projects write their user stories / implement them; Integration team continuously works with Use case subcommittee to accompany the use case development, review epics/user stories, answer questions, etc. Use case subcommittee behaves as system engineers for the use case through test start date
9. Integration team defines the gating use case based on step 8 and finalizes the PNFs / VNFs selection, with the help of use case subcommittee, architecture subcommittee, PTLs of a different ONAP projects
10. TSC approves the gating use case
11. Integration project leads (coordinates) effort to get the gating use case tested, repaired, and verified, and the results are documented.
- There were no questions or proposals for the existing R1 use cases
- Yan Chen has presented Enterprise vCPE Use Case targeting ONAP R2. The received comments were to add justification part to the use case description, to consider equipment extensions e.g. VNFs, open sourced or commercial, and to add flows
- As we will have to decide which R1 use cases extension/R2 new use cases are beneficial, it is proposed to have justification section per each brought use case.
- We agreed there are 2 use cases categories: those purely based on new models/new configuration and those required components extension/new components introduction. The former may not require interactions with projects etc. per phases defined in (1), while the latter does. In case of former, we may decide to recommend it for inclusion in the present release, and it will be up to Integration team to decide whether the task id feasible.
- For the R1, we reached step 6 from the Italic list above. Thus, we need to get architecture subcommittee feedback urgently. This feedback should include:
- What architecture subcommittee plans to define for R1 and when
- Which decisions should be taken by the projects themselves
- Also, a direct communication should be established between the Integration team/PTLs of the other projects and the use cases teams to speed up the process, per Helen’s request. This would follow (6) above i.e. whether input is expected from Architecture subcommittee or direct work with use case teams can be established. Yoav and Jon from Amdocs (they are cc’ed) are contacts for vCPE use case. I asked for the contacts names for VoLTE use case – will communicate once I get those.
- It was clarified that we should provide our R2 use cases proposal by September meeting. This would include steps 1-4 from the Italic list above. For that, all interested companies are required to start bringing their R1 use case extensions/new R2 use cases proposals ASAP. It would be beneficial to get those in advance before each meeting in order to have constructive discussion.
A general point – right now, bi-weekly calls are scheduled. Subject to load and responsibilities split, we may decide to move it to weekly meetings. Let’s discuss it next meeting.
Also, a dedicated use case subcommittee email list was created – please subscribe. I plan to move all related email exchanges over there in a week from now.