Agenda

Antitrust Policy

• Roll Call

• Agenda Bashing

• Way of Working

• Recap of CAMARA procedures and Dedicated Networks API proposal

• Discussion

  • Issues and Pull Requests

Minutes

First meeting 

• Antitrust policy (expect all participants to be aware)

• Brief introductions from the members

Way of working

• Meeting minutes in Wiki instead of Git

  • Check in / approve meeting notes in subsequent meeting

  • Dedicated meeting note maker

    • Rajat for the first meeting

• Agenda before the meeting

  • Thorsten: Probably overtime normal workflow (reviewing issues, etc.) but sometimes need to announce.

• Tanja: Project reporting to CAMARA All hands

  • Reporting on 4th Thursday every month (Next on - 18 Nov 2024 (tbd))

  • Editing on the main page of the all-hands wiki (can look at minutes from last time)

  • Thorsten: Not necessary to be physically present, ?

  • Tanja: Ideally presented, but otherwise people are reading

• Meeting time

  • 10:00 - 11:00 CET (winter time) - need to go to UTC over time.

  • WG Members to suggest if current time doesn't work for them

  • OK from all members to keep current slot

• No other governance aspects raised

Recap of where we are in CARAMA process

• Thorsten: API onboarding process - submitted the proposal, cycled through the API Backlog WG, then brought up at the TSC, agreed as a Sandbox API (repository assigned and can start working)

• Sub Project has taken ownernhip per the API management and maintenance

  • Versioning guidelines to be followed

  • Checklist items need to be considered

• Thorsten: Suggest to start with API Documentation and first API definition

  • Tnen start to work on the subsequent items of the checklist (e.g. test definitions)

• Linting rules contributed by Vodafone (PR exists)

Formally submitted docs in API backlog

Description: https://github.com/camaraproject/APIBacklog/blob/main/documentation/API proposals/APIproposal_DedicatedNetworks.md

Slides:

Thorsten: Anything to be discussed or phrased differently? (See bwlow)

Peter: Do we also want to monitoring these resources once they are reserved. Would they fall under this service?

Thorsten: Good question but relations to other APIs. Suggest to start simple, but should not exclude this use case

Peter: Yes, would not do first but for completeness (of the API / features) should be considered

Thorsten: State machine available, but where to plug and which APIs etc to be discussed

Thorsten: No only about the reservation / booking phase, but also include the time when network is available. Should be able to add/remove devices in preparation, but also in the available network / runtime when network is being used.

Thorsten: Related API (Slide 7 from above) (Monitoring / network insights not mentioned), QoD API perhaps the most relevant to think about, network slice booking but difference in including connectivity, monitoring, etc.

Thorsten: Slide 8 - use cases - not sure if it was discussed in the preparation phase. Three use cases introduced. In all three cases, there is a planning phase (press briefing, time is known, devices are known), then producer wants to use different connectivity performance at runtime. WHere, when, how many devices, and related performances are fed to the API.- Once there is acceptance, reserved resources should be secured. Only when nw becomes available, nw becomes usable.

Thorsten: Festival: For organizers running the festival (not ppl attending necessarily). Dedicated network needed for certain duration in certain area.

Thorsten: Enterprise Connectivity: when video conference starts, certain quality is assigned, once over - released and can be used for other devices.

Thorsten: Checkpoint: IS the above inline?

Peter: Aligned but heavily leaning on Quality on demand.

Thorsten: Yes, easiest to explain but other types of services havent been discussed yet. (Request to elaborate)

Peter: need to reserve, then request qod on those, dedicated networks is more about reserving these services. May be people will not apply qod on these networks. When no dedicated networks, cannot do it at all. but if avialable, qod is possible. main thing here is a way to reserve nw resources. What it can be used for is up to implementation.

Thorsten agreed, on the reservation side. bit which resources need to be reserved need to be identified.

Reserved state - can possibly make changes, also may need “time to reserve”

Additional comments:

Tanja: States - operation perspective may be more states than these. need to look at other states. TMForum has a set of standard operational states. Can be done when the work starts.

Thorsten: Agreed, names for states - but at least two are needed

Tanja: Device types that need to be managed? Can look later.

Thorsten: Yes resources and relation to device types needs investigation.

Summary:

Thorsten: Seems like a good common understanding. Work can start. How / where?

• CAMARA WoW: Create issues and then PRs to address them

• README: CHeck if any information is missing

• How to start filling details

  • Thorsten: Jumping to YAML is quick but is it the best step

    • Tanja: Create API Release tracker page. Gives a number of starting points. One of them is the checklist.

      • Checklist has use case (not sure if mandatory for 1st release)

      • API Tracker Is on Wiki and makes it visible to people. (release ad versioning aspects)

      • Meta release is every 6 months - next one is Spring 25.

      • Maturity: initial (or go stable)

      • Tanja: Have to start with initial and then have some proof of usage to classify as stable

      • Tanja: Copy checklist into repo. Initial API - basic tests (but stable full suite)

      • Tanja: Scope: create issue in github that describes what the API is doing. All the PRs related to creating this scope are the ones that contribute to

      • Tanja: PR for dedicated set of changes.

      • Tanja: Should be fixed by the M4 milestone - (when it is ready for testing by others) (M3 - is the final api ready)

      • M3 date for Spring 25 is Dec 31. So not possible to target Spring 25. Need to target Fall 25. Next M3 is June 21 2025.

      • Thorsten: Work on the API tracker page till next meeting. (Action point to all).

  •  

Action items