Agenda / Minutes

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.

• Minutes of last Meeting (link)

• Issues and Pull Requests:

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

• New PR:  [bulk] Sync Release Information section (2025-12-12-001) by hdamker-bot · Pull Request #89 · camaraproject/DedicatedNetworks

•  

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

  • PR: Format profile id as UUID by hubertp-ericsson · Pull Request #83 · camaraproject/DedicatedNetworks

    •  Merged during the meeting

    •  

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

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

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

    • PR to Commonalities: New 409 error code called INCOMPATIBLE_STATE by tlohmar · Pull Request #550 · camaraproject/Commonalities

    • Commonalities: Duplication of error code semantics, i.e. CONFLICT and ALREADY_EXISTS · Issue #562 · camaraproject/Commonalities

      • Detailed Analysis: https://github.com/user-attachments/files/23828658/409-consolidation-recommendation.md

    • Can we merge PR#81 without bumping the Commonalities version?

      • See Commonalities (Link), Section 3.1, NOTE 2 & NOTE 3:

        •  NOTE 2: A {{SPECIFIC_CODE}}, unless it may have traversal scope (i.e. re-usable among different APIs), SHALL follow this scheme for a specific API: {{API_NAME}}.{{SPECIFIC_CODE}}

        • NOTE 3: Meaning of {{API_NAME}}.{{SPECIFIC_CODE}}. The double curly brackets '{{..}}' represent a placeholder to be replaced with the real values for the exception. API_NAME is the value of api-name in SCREAMING_SNAKE_CASE format while SPECIFIC_CODE represents the value agreed for a given API error case scenario, in SCREAMING_SNAKE_CASE format as well (e.g. CARRIER_BILLING.PAYMENT_DENIED).

      • → Seems that Commonalities allows using new Error Codes. Should be checked with Commonalties?

• Issue: Definition of "Max Number of Devices" of the NW Profile · Issue #85 · camaraproject/DedicatedNetworks

  • New PR: Adding description of the MaxNumberOfDevices parameter by tlohmar · Pull Request #88 · camaraproject/DedicatedNetworks

  • Suggestion: Make the maxNumberOfDevices an optional parameter.

    • Update the PR to make that optional.

  • Error Code, What EC is used by TMF648 Quote Management API? TMF 648 uses a 409 Status Code

    • Suggestion: 409 (INCOMPATIVE_STATE) or 422 (NEW Error Code)

      • to be aligned with QoS B&A needs

•  

• Issue: Support for managing multiple devices · Issue #70 · camaraproject/DedicatedNetworks

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

  • Hubert: I am working on a consolidated response to the raised questions / comments. Thus wip.

  • Stefano: Potentially propose this PR as commonalities extension.

    •  

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

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

    • The issue was closed in commonalities. CloudEvents also use ‘id’ (not eventId). The use of Status parameter seem to have a similar ambiguity issue.

    •  Should document the current thinking and way forward, when closing the issue.

    •  

•  New Issue: Finding suitable areas where a reservable connectivity service can be provided · Issue #86 · camaraproject/DedicatedNetworks

  • New PR: Hubertp areas api by hubertp-ericsson · Pull Request #87 · camaraproject/DedicatedNetworks

  • AP: Create some slides / illustrations, how the different Ids are used with each other, i..e A NW reservation Request is created by …

    • Example: three customers are reserving a network at the same area, with the same NW profile for the same time…

  •  

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

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

  • Should be clarified in ICM. Consistency around usage OAuth Client Credentials grant flow · Issue #284 · camaraproject/IdentityAndConsentManagement

    • Since the last comment is older than a month, we need to revive the thread.

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

  •  

• Issue: [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

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

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

The meeting on 29th Dec will be cancled.

Minutes

Agenda 1

• Comments

Action items