Agenda

Antitrust Policy

• Action Items Review

• Agreement of last minutes (Link)

• Action Items Review

  • Issue at CAMARA Governance (Issue #172): Verbal answer during the meeting: Approval by one CodeOwner (who is not the contributor of the PR) unblocks the merging. Still, agreement according to the CAMARA process description is needed before merging.

  • Issue #16 is closed. Issue #17 (Correlating a Dedicated Network resource within a subsequent IoT Data Transfer Activation API call) is open

• Issues and Pull Requests

• Issue #11: Usage Scenarios for Dedicated Networks

  • Pull Request #12: Description of Usage Scenarios for the Dedicated Networks API

• Issue #10: API Design Requirements

  • Pull Request #15: API Design considerations

  • New Pull Request #18: Initial API Proposal for Dedicated Networks

    • MegaLinter failure (Link):

Minutes

Review of Action Points:

• Thorsten: Created PR in Governance (#172) and discussed in TSC / API Backlog. One CODEOWNER needs to approve before it can be merged (other than the Contributor). CODEOWNERS automatically added to review. Maintainers need to be added manually.

• Rajat: No update on images. Request to leave open.

PR #12 and PR #15

• Merged in the meeting. Agreed that since they are living documents - changes in future versions are to be expected. Members agree that having some info public is good to make progress.

New PR #18 - Initial API Proposal

• Megalinter issue - seems like it is more restrictive.

• Thorsten walked through the slide deck (no notes made other than Q&A)

  • Slides:

  • Peter - question on “networks” - how do you identify the CSP?

    • Thorsten: API is exposed by a specific CSP. If there is an aggregator, then there might be a need to have a CSP ID.

    • Rajat: Seems like a common concern across all CAMARA APIs. May be could check how other subprojects approach it.

    • Hubert: Could / should be handled at a higher level.

    • Barath: Enterprise (ASP) has to subscribe / signup for specific APIs from CSPs perhaps?

    • Peter agreed to create an issue in DN but mentioned should also be raised at a CAMARA level.

  • Surajj: States - Deactivate / Suspend seem similar

    • Surajj: ASP may not have paid bill, so can be “suspended”

    • Difference between reserved and suspended was discussed

    • Thorsten: Do we want to model such “monetization” related aspects in the API.

    • Peter: Reserved and suspended seem like the same.

    • Thorsten: Can consider renaming and add more text in API docs

  • Masaharu: Service Area

    • Masaharu: how to use the label? Who specifies the label?

    • Thorsten: Current mental model - as part of the onboarding process (and not directly related to this API). CSP and ASP can agree in advance. Can be dynamic also but may be assumption to start is static

    • Thorsten: CSP defines it - can be based on topology and/or use case specific requirements.

    • Thorsten: other areas than labels (e.g. polygon) can also be used.

    • Masaharu: Also considering the same in another API

  • Thorsten: General question

    • Almost no real descriptions in. In other APIs - pretty elaborate descriptions. How to clarify the usage?

    • Should we start descriptions out of PRs and have a separate API design considerations or should we start to expand the PR?

    • Thorsten: Progress the descriptions in different document - and then new PR to merge.

    • Thorsten: Docs need to be started soon.

  • Peter: The usage of QoS Profiles in this API. Related to “core network” concept and PDU. DN covers radio and transport, etc.

    • Thorsten: Tput and QoD modelled differently in the “dedicate-network-profiles” yaml.

    • Thorsten: For each PDU still some default needs to be defined in DN.

    • Keep open for future meeting / potentially start here.

    • Hubert: DN profile is different than QoD profiles. We model it such that network profile is constructed of a number of QoS profiles and also defines the default.

Action items