Hi @benhepworth , thanks for the presentation to the API Backlog call 25th July - as mentioned on the call, there appears to be overlap with Connectivity Insights. From the scope in #70 :

report application KPIs to network operator

• in Connectivity Insights the application developer provisions an application profile to the operator, detailing the network performance thresholds it can tolerate for acceptable customer experience. It includes throughput on uplink and downlink, packet delay ('latency'), packet delay variation ('jitter'), and packet loss.
  Although this profile is provisioned in advance it can be updated, but any ability to match an updated profile to an existing flow would require an additional API request.

receive QbD score

• Connectivity Insights merely states if the profile thresholds can be met ('good') or not ('bad'), which may be simpler for the operator to determine, but is probably less useful to the developer than a robust calculation (e.g. Quality Attenuation/Quality Of Outcome based)

receive root cause analysis and recommended corrective actions

• not done in Connectivity Insights

request service improvements

• not done in Connectivity Insights. But is done in Quality on Demand.

@maheshc01 may offer some additional insights (no pun intended) - but overall it would be good to either harmonise or agree how to split the scope.

Thanks for the feedback @Kevsy . I just joined the ConnectivityInsights mailing list and I see there is a meeting this week. I will email that group to see if I can get on the agenda for this Wed's meeting. There is definitely some overlap and maybe this does indeed belong over there. I'd like to chat further about details with the ConnectivityInsight group and make sure that is the right place for this to land before closing this. ConnectivityInsight has some stuff already that we could re-use (i.e. application-profiles), but there are some things it doesn't have (i.e. a way to send metrics). Will post a more detailed update here after meeting with ConnectivityInsights sub-group.

Met with the Connectivity Insights group on 8/14. The decision from that meeting is to:

• Add the Quality by Design API to the Connectivity Insights family at CAMARA
• Quality by Design will reuse the application profile from Connectivity Insights
• Preference is for Quality by Design to get it's own repo rather than be in existing ConnectivityInsights repo

Link to meeting notes here.

@camaraproject/api-backlog_maintainers - we are ready for this to go to the TSC for a decision. What are the next steps?

hey @jgarciahospital - is there anything else for me to do on this in order to get this before the TSC in their next meeting? How will I know when this is on the agenda?

Pending issue solved, API is now proposed for TSC approval.

Just that the repository is not yet created (will come soon), and there is the need to collect the code owners and maintainers. Will that happen within the issue? (note: the issue will be closed as well with the PR due to the "fixes:" above)