2025-12-01 Dedicated Networks (Breakout) Minutes
Community Attendees:
@Thorsten Lohmar @Steve Vickers @Stefano Brivio
Community Attendees:
LF Staff:
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:
PR in Commonalities to extend Status Code 409 with a INCOMPATIBLE_STATE (WRONG_STATE). This wrong INCOMPATIBLE STATE seems more generic and can be applicable for other APIs.
(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
Thorsten’s thinking to start with a Ball-Park, but define an Error Code. It can be seen as an API provider policy, how many more devices are allowed, e.g. 10% more or even 0% (hard limit) more.
Stefano, we many need to think about admission control at run time (run time == network is activated). Thorsten, there is also the ToC, which can make the responsibilities for the ASP clear.
We need to separate between the admission control and access control. → We need to make this clear in the API description.
Suggestion: Make the
maxNumberOfDevicesan optional parameter.Error Code, What EC is used by TMF648 Quote Management API?
Issue: Support for managing multiple devices · Issue #70 · camaraproject/DedicatedNetworks
Should update the DedicatedNetworks_GeneralDescription.md including the usage of Device Groups. AP, create a separate PR
Current API spec seem to be inline with commonalities, i.e. no requirement on property naming. Brought as a discussion to commonalities.
Issue in Commonalities: 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.
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…
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] 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
Ussie: Application Developers use cases · Issue #20 · camaraproject/DedicatedNetworks
Minutes
Agenda 1
Comments