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)

• Action Items Review

• General Aspects

  • Update of the API Description: DedicatedNetworks API description - CAMARA Project - CAMARA Project

  • Proposal for Issue #12 - qos-booking-and-assignment.yaml by RamTMO · Pull Request #29 · camaraproject/QoSBooking

  • EBU has just published a new report on "PMSE connectivity for production – mapping use cases" (link). PMSE stands for Program Making and Special Events, i.e. the name of the media production vertical.

• Closed Pull Request:

• Issues and Pull Requests:

  • Issue #8: Scope of Dedicated Networks API version 0.1.0

    • Pull Request #34: Release R1.1 with API version v0.1.0-rc.1

      • Updated to address blocking comments

    • Issue #41: [General Description] Add references to 3GPP Release versions

      • New PR#51:

    • Issue #45: [Accesses API] Improve documentation on when accesses can be requested

      • New PR#53:

    • Issue #49: [Accesses API] Clarify why IP address is omitted from Device object

      • New PR#55:

    • Issue #48: [Profiles API] Improve description of QoS Profiles

      • New PR#54:

      • New PR#59: Aligning QosProfileName definition with QualityOnDemand by tlohmar · Pull Request #59 · camaraproject/DedicatedNetworks

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

    • Issue #56: Remove oAuth2 security scheme

      • PR#57:

      • Already Handled in Pull Request #34

    • New PR #58: Providing device identifier with the access token

  • -----------

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

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

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

    • The initial description is on 2-legged vs 3-legged, not about the OIDC Discovery protocol. Thus, the Issue seem to contain two sub-issues.

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

    • to be brought to commonalities.

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

  • Issue #39: [Accesses API] x-device Header clarifications

    • to be brough to commonalities, since current commonalities allow using a header within GET operation or the body in a POST operation for providing sensitive information. The topic on 2-legged vs 3-legged access tokens is a separate issue.

Minutes

• API Description in Wiki (cleaned up by Thorsten, required for M4 - to be published on CAMARA website)

• QoS Booking API PR discussed: Seems like a discussion is required with the QoD group

• New PRs created by Thorsten to address some of the newly created issues. Target to include them in release version for fall meta 25 (or in next rc).

  • Clarified reasoning for choosing specific 3gpp versions.

  • New PRs planned not to be merged until RC PR is merged

  • Update PR#51 to point to absolute URLs (esp. in YAML files) (@Thorsten Lohmar )

  • Comment from Rajat on copying schemas from other WGs, instead should be a reference to a schema elsewhere for correctness / completeness and to avoid overhead for maintenance.

• Items to bring to commonalities

  • Guidelines on the device object (and if/how to introduce ip addresses)

  • Issue 42

  • Issue 39

  •  

Action items