Page History

...

...

• EasyCLA vs Developer Certificate of Origin (DCO) (Casey Cain )
  • Debrief from CAMARA Board Meeting and leadership call CAMARA / LF / GSMA
  • GSMA / LF Catch-up  (June 5th) - push to use EasyCLA but no decision at this stage. We need need to solve the GSMA issue in cooperation with GSMA & LF (Link to the file-header). Target to close on this topic for next TSC  

• "Codeowner" and "Maintainer" for the Governance repository (#138) (Herbert Damker)
  
  • Process to change content in https://github.com/camaraproject/Governance is currently not defined, especially for important changes of ProjectCharter and other Governance documents
    • Nevertheless it is clear that changes are in the responsibility of the TSC
  • Proposal:
    • Chair and Co-Chair of TSC as "Codeowners"
    • All TSC Participants as "Maintainers", following the same rules like in Sub Projects
    • Creating a GitHub team "TSC_participants" for this purpose (which can be used to request input on issues or reviews on relevant PRs)
  • Decision: Approved & to be executed like this.

• New proposal how to manage "API Families" as Sub Projects with one lead repository and multiple API "family member" repositories (#142) (Herbert Damker )
  • See issues about problem statement and proposed solution. It is a replacement for the previous proposal in #135 (working groups across Sub Projects).
  • Proposed next steps: close #135 and create a PR for the new proposal to enhance ProjectStructureAndRoles.md accordingly (Herbert Damker )
  • Discussion
    • Comments to the issue should be provided before June 11th.
    • EdgeCloud provides an example with SimpleEdgeDiscovery
    • Question related to the Wiki pages for NV, SIM SWap & OTP - if it becomes a family we will need to have one wiki page. Anyway we need to be consistent between the wiki structure & the GitHub organization.

• Proposal for new API Project lifecycle approach (Sandbox + Incubated) (#129)
  • Proposal to postpone until the previous point is done (#142)

...

• Ongoing project organization tasks (just in case there are questions)
  • Create CAMARA teams for Codeowners & Maintainers - apply to all sub projects (#134)
  • Update of README.md structure in all sub projects (#124)
  • Change Working Groups into Sub Projects (#84)
  • No comment from the team

API Backlog (Ricardo Serrano Gutierrez )

• Ricardo: Assessment in progress for new APIs but no API to be  proposed at TSC level for today.
• Template for scope enhancement (of existing APIs): https://github.com/camaraproject/APIBacklog/pull/52
• Eric raised the question about the commitment of "becoming a supporter" for an api proposal. 
  • For Herbert it means at least nominates a maintainer. The question could also differ if the new API is part of an existing family (in this case it is related to #142).
  • Ricardo agreed and we can write something to establish this.

Commonalities (Rafal Artych )

• Release 0.4.0-alpha.1 - https://github.com/camaraproject/Commonalities/pull/222
  • API testing guidelines
  • Main topics already merged except: API Testing guidelines and Error Response revision in chapter 6
  • We target to finish for this end of the week.
• Device object definition - https://github.com/camaraproject/Commonalities/issues/171

The solution proposed to be covered in the scope of this meta release was:

1. 1. Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios.

   2. Remove the networkAccessIdentifier from Device object

Action: should be good to ask sub-project to assess impact on this discussion ( should be discussed in sub-project meeting) → Raise an issue in impacted projets like QoD

• Adapt API Guidelines to ICM Securtiy Security and Interoperability Profile -  https://github.com/camaraproject/Commonalities/pull/208

  • Agreed in ICM: https://github.com/camaraproject/IdentityAndConsentManagement/issues/160
  • Mark raised the point about diversity of using either authorization code flow and/or CIBA but we need to be careful. Straightforward question: Is it one of the either or both? do we mandate something?
    • Axel Nennker opened a discussion in ICM but with no real result of a global direction because it'is up to API implementation.
      • Sub-project can indicate if & how they are supported CIBA. 
    • Diego González Martínez raised that we need to decouple the "how the developer get auth flow accepted" from "how we manage several possible auth flow for one API"
    • We can have a 'decision' at sub project level to 'device' which authorization flow will be supported. Need anyway to see how this 'information' will be communicated.
    • Move this discussion in ICM.
• Alignment with Release Management and ICM for Release Candidate

...

• ICM examples was created
• Commonalities API Design Guidelines PR agreement was reached in ICM on June 5th. 
  Still being worked on but close to being finished
  • Axel & Diego discussed about the redundancy of information between ICM & Commonalities - minimum should be duplicated and links should be provided.
• CAMARA APIs access and user consent management adaption to CAMARA Security and Interoperability Profile finished.
  Still some discussion on what network authentication "authenticates", user vs subscribtion subscriber discussion.
• Working on ICM release plan

...

• Progress of meta-release plan: Meta-release Fall24. 2 APIs were added.
• Commonalities and ICM M1 shifting into June; M2 still kept on 15/06
• Commonalities and ICM may have to prioritize the closing of main functional/technical issues or decide to move to next meta-release in order to reach an alpha release ASAP. 
• Release Management issues status: see 2024-06-04 Release WG Minutes
• The API release tracking page has been added to all API Sub Projects (thanks to Casey)
  • For new Sub Projects this page will be automatically created in the Confluence page structure. The RM documentation needs to be updated accordingly.
  • API Sub Projects can create their API tracker(s) by clicking on the button on the API Release Tracking page and following the guidelines. There should be one tracker for each API and its version they plan to publish in the meta-release
• Updated API-Readiness-Checklist PR available for review: Add API-Readiness-Checklist.md to RM project
• Actions:
  • Presented in all-hands call newt week (June 13th) featuring an example
  • Send a communication to all mailing list to informe about the release management and associated action;

Any Other Business

• ...

Next Meeting

• Next TSC Meeting will be on June 20th at 16:00 CEST / 14:00 UTC / 07:00 PST
• Specific agenda topics backlog:
  • ..No specific request but feel free to propose till next meeting.

Action items