2024-10-24 API backlog minutes

Attendees

 Agenda Proposal

• Antitrust Policy

• Approval of minutes of last conf. call

• Recent Updates & Recap

• Review of Action Points

• Discussion

  • OGW APIs:  #35 (5G New Calling),  #50 (Device Management), #63 (IMEI Fraud), #91 (Fixed lines in Device Location APIs), #93 (Line Eligibility for Carrier Billing API),  #95 (IoT SIM Status Mgmt API), #96 (IoT SIM Fraud Prevention API), #97 (IoT SMS send API)

  • Other APIs:  #17 (Consent and Measurement),  #23 (Carrier Wholesale Pricing),  #24 (Steering of Roaming Information), #89 (IP High-throughput Elastic Network) 

  • Governance: #4 (Structures and roles, RACI, Maintainers initiative)

• Closing Issues

  • #22 (Capability and Runtime Restrictions), #18 (Receive SMS),  #54 (Number Recycling), #70 (Quality by Design), #34 (Shutdown Service Status), #41 (Telco Scoring), #60 (Dedicated Networks), #66 (network Info), #20 (Best Interconnection), #68 (Consent URL), #83 #85 #86 #87 (Model as a Service)

• AoB

• Q&A

Antitrust Policy

The project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LinusFoundation.   Antitrust Policy

Open

New Procedures in API Backlog WG meetings

A number of improvements are under discussion with leadership team of OGW project (Henry), CAMARA Project (Markus), Product Definition WS (Helene) and TSC (Herbert). As of today, the WG adopted agreements are three:

1. To close the agenda SEVEN DAYS BEFORE the conf. call.

   • In case a WG participant wants to include a point in the agenda (e.g., present a new API proposal), this participant shall ensure the corresponding issue is opened in Github by then.

   • Exceptional situations will be treated separately.

2. New schedule of conf. calls **The meetings are to be held by Linux Foundation (Links available at GitHub and Confluence Backlog front pages)

   • 2nd Thursday of the month (9-10:30 UTC)

   • 4th Thursday of the month (15-16:30 UTC)

3.  Send agenda to TSC mail list, to encourage more TSC member companies to join the call and provide comments when they identify APIs which are of interest for them. 

4. New API proposals are included in backlog table when template PR is created, linking to the pending PR

5. PR will be merged as soon as ready for TSC, and should be merged before TSC review

6. API enhancements requires existing group’s validation. TSC is informed accordingly to validate

7. Link and status in backlog table will be updated accordingly

Approval of minutes of last conf. call

• Minutes of last API backlog WG call available here

  • DECISION: Approved

Recent Updates & Recap

TSC meeting 17th October:

• Repository for CustomerInsights created (was approved as “TelcoIndex” in TSC 2024-09-19)

• New API proposals brought to TSC (3):

  • Model As A Service Family:

    • Supported by China Mobile, ZTE, Huawei. Filled template(below). Original issue: 83. Additional material:

    • Family proposal: New CAMARA Family to manage Model As a Service features. Includes different APIs that enable a end-to-end management of an AI model that can be exposed to third parties, with following functionalities:

      • Link1. Knowledge Base - Management (configure a user-specific knowledge base to support the construction of Q&A assistant)

      • Link2. Q&A Assistant - Management (configure specific LLM assistant with particular models)

      • Link3. Q&A Assistant - Service (usage of LLM, prompts and responses)

    • Decision: no comment - Reminder: This API will go in the sandbox. Approved !

  • Capability and Runtime Restrictions:

    • Proposed by TMUS. Filled template: link. Original issue: 22. Additional material:

    • Not API proposal per-se, but a capability that could allow developers know which optional features are supported by the telco operator before an API is called (This is a complementary API). Proposal is to create a mechanism to report

    • Could be considered as a transversal feature for any API, as per original CAMARA Service Management API APIs.

    • Question from @diego.gonzalezmartinez is this an API? Response: yes to request subscription in order to get notification.

      • For @diego.gonzalezmartinez we should have small API and all the API implemented. Having same API with different level of implementation is an adoption issue. We can have exceptions.

      • Is it valuable for a developer to discover on the fly an API limitation? Diego is doubtful about the rationale.

      • @Ludovic Robert and @Mark Cornall echoed Diego perspective.

      • @Murat Karabulut provides an illustration where depending on the (US) States the API may request distinct attributes list. Another example is documented for KYC Match in which idDocument is mandatory in some regions.

    • @Shilpa Padgaonkar : let’s leverage the sandbox capabilities to let this API grow up. Sandbox gives a chance to develop API idea.

    • @Jose Luis Urien Pinedo raises the point about the synchronization with the TMF operate API - The restrictions should be also defined in this flow.

    • Comment: Concern was expressed that such an API, even if developed as a sandbox, might give the wrong impression to external viewers of CAMARA was proceeding - in this case the concern that API providers will only implement a subset of an API’s functionality and use this API to advertise that once the API consumer has access. Some thought should be given as to how sandboxed APIs are to be “isolated” from incubated APIs to avoid giving this impression.

    • Decision: Ask to @Murat Karabulut to provide some examples where this API will be useful. To be revisited during the after-next TSC meetingNov 14, 2024 .

  • Consent URL API:

    • Supported by Telefonica and KPN. Filled template: link. Original issue: 68. Additional material: link

    • Meant for providing an out-of-band consent gathering mechanism that can be triggered in a separated moment (apart from API authentication phase) and in an arbitrary device (not only the API-targeted device), enhancing current mechanisms tied to Authcode or CIBA token flows.

      • Discussed with ICM WG in particular to define the relationship between this API & ICM

      • Open discussion, as lack of consensus around AuthCode authentication mechanisms (https://github.com/camaraproject/IdentityAndConsentManagement/issues/215 )

        • @Axel Nennker strongly disagrees with this API rationale

        • @Shilpa Padgaonkar Probably the issue comes from the fact that initial assumption is we use only Network-based authentication.

    • Comment: The discussion within ICM #215 indicates there may be a lack of clarity as to which of CAMARA’s “guidelines” are normative and which are only informative and hence not mandatory. TSC may need to look at formalising rules on this regarding documentation language, layout and approval processes.

    • Decision: The discussion must continue in ICM first. No decision at this stage.

Other topics

• GSMA informed CAMARA Backlog that Open Gateway is considering certain Drop2/3/4 APIs that have been stuck in Backlog, “at risk”, due to lack of support. What this means is that GSMA is pushing our MNOs to actively reconsider within the next 2 weeks if they can support them. By raising it in the Backlog meeting we increase the chance to find enough support to “reactivate” progress. 

  • Best Interconnect

• (new) Sandbox proposal from TSC to speed-up the inclusion of new APIs into CAMARA, fostering the development of new APIs and the finalization of API scope definition. 

Backlog table

• Table finally updated following last APIs:

Backlog procedure to update table from now on:

• New API proposals are included in backlog table when template PR is created, linking to the pending PR

• PR will be merged as soon as ready for TSC, and should be merged before TSC review

• API enhancements requires existing group’s validation. TSC is informed accordingly to validate

• Link and status in backlog table will be updated accordingly

Discussion

Current Issues