Agenda

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

•  

• Agreement of last minutes (link)

• TSC agreed, that the Dedicated Networks API is continued under the umbrella of the QoD Working group. See 2025-09-18 TSC Minutes - CAMARA Project - CAMARA Project

  • Wiki Page already moved.

  • Regular Community meetings on every second Fridays at 1300h UTC (14:00 CET, 15:00 CEST).

    • separate breakout meeting on a need basis.

  • Only one Mailing list, i.e. sp-qod@lists.camaraproject.org (will be renamed soon, see Find a better name for the Sub Project Quality On Demand (not the API) · Issue #498 · camaraproject/QualityOnDemand).

    • the mailing list sp-dedicated-networks@lists.camaraproject.org will be removed.

    • Please ensure to subscribe to the qod mailing list

    •  

  • API description published (with picture) (see link)

• Closed Pull Request

  •  

• Issues and Pull Requests:

  • Scope of Dedicated Networks API version 0.2.0 · Issue #69 · camaraproject/DedicatedNetworks

• Enhancement to support managing multiple devices per Device Access by hubertp-ericsson · Pull Request #71 · camaraproject/DedicatedNetworks

  • The PR was submitted during the meta release finalization work. so far, no comments. From lazy consensus perspective it seems agreeable.

  • AP Hubert: Resolve the conflicts.

• Remove `oAuth2` security scheme · Issue #56 · camaraproject/DedicatedNetworks

  • (closed)

• [Profiles API] NetworkProfileId is a string but format is not yet specified · Issue #47 · camaraproject/DedicatedNetworks

• [Accesses API] Improve error handling when access is requested at incorrect time · Issue #46 · camaraproject/DedicatedNetworks

  • Suggestion to use Status Code 409 with a DN specific code. Hubert will create a PR

  • New error code when network in wrong state by hubertp-ericsson · Pull Request #81 · camaraproject/DedicatedNetworks

  • Adds a new Error Coder 409 with Wrong State. We should make it clear in Issue #46, that Code 422 is not usable for Non-Device related identifiers.

  • No comments on PR #81. Can wait until next meeting.

  • New PR in Commonalities to extend Status Code 409 with a WRONG_STATE (AP for Thorsten). This wrong WRONG STATE seems more generic and can be applicable for other APIs.

    • (Related Meaning of {{API_NAME}}.{{SPECIFIC_CODE}} · Issue #538 · camaraproject/Commonalities)

• [API Design Guideline] Potential usecases / reuse of DeviceResponse Object · Issue #44 · camaraproject/DedicatedNetworks

• [API Design Guideline] Does an API not implementing OIDC Discovery make it non-CAMARA compliant · Issue #43 · camaraproject/DedicatedNetworks

  • Should be clarified in commonalities. Since the last comment is older than a month, we need to revive the thread.

• [API Design Guideline] "id" could be more descriptive in payload · Issue #42 · camaraproject/DedicatedNetworks

  • Current API spec seem to be inline with commonalities, i.e. no requirement on property naming. Concluded understanding to be confirmed with commonalities. AP Thorsten

  • Relations between in-path identifiers and in-payload identifiers · Issue #540 · camaraproject/Commonalities

    • Direction of Commonalities still unclear, since CloudEvents is following a different id naming principle than other APIs. The existing API seem to be still inline with commonality rules.

• [Accesses API] POST operation is synchronous - may be there are use cases for async. · Issue #40 · camaraproject/DedicatedNetworks

  •  

• [Accesses API] x-device Header clarifications · Issue #39 · camaraproject/DedicatedNetworks

  • To be brough to commonalities: (A) can we continue using GET with a header and (B) is there a benefit of harmonizing using of device object in header. Two approaches: Either create individual headers for each device object property (as done in simple edge discovery) or serialize the device object (as done in Dedicated Networks)

  • Open

• dedicated-network-accesses.yaml missing device lifecycle · Issue #21 · camaraproject/DedicatedNetworks

• Application Developers use cases · Issue #20 · camaraproject/DedicatedNetworks

Minutes

Agenda 1

• Comments

Action items