Merge branch 'main' into patrice-conil_issue42

documentation/API-DocumentationTemplate.md

@@ -8,10 +8,10 @@
 |Documentation|Details|This is an optional section/placeholder. It could include some detailed descriptions or diagrams explaining things in further details and the subsection heading could be changed accordingly.| |
 | |Endpoint definitions | What does each endpoint do is a critical part of the API documentation. It explains the consumer/developer your internal system. The documentation should explain what an endpoint is for and how it relates to other endpoints. It should also document:</br> - HTTP verb methods supported. </br> - Parameters along with description </br> - HTTP codes expected + HTTP response bodies </br> - HTTP Request and Response headers </br> - Pagination details if applicable </br>If there are any constraints for an endpoint, it should be documented in this section. </br> It should be made clear if certain endpoints are restricted to only certain roles/users. | Yes |
 |  |Errors|Error types along with error codes summary table can offer a good reference for the developers working with the API | Yes |
-|  |Policies|How the developer can discover the usage policy for each endpoint - e.g. limits on requests per second, any regional limitations on what can be returrned in the resource representation, etc. These policies will be operator-specific but the mechanism to discover them should be consistent | No |
+|  |Policies|How the developer can discover the usage policy for each endpoint - e.g. limits on requests per second, any regional limitations on what can be returned to the resource representation, etc. These policies will be operator-specific, but the mechanism to discover them should be consistent | No |
 |  |Code snippets| Copy-paste sample code snippets help developers to get started right away. It helps provide a rich developer experience. This can include sample request examples, and the ability to execute samples directly from the documentation Web page (as per Open API). | No |
 |  |FAQs| List of frequently asked questions by the early developers/users of the API |No |
 |  |Terms|Terms of Service |No (N/A for Camara|
-|  |Release Notes|Listof all changes included in the release |Yes| 
+|  |Release Notes|List of all changes included in the release |Yes| 
 |  |Pricing |Details about pricing |No (N/A for Camara)|
 |API Spec || Complete API Spec in YAML format | Yes |

documentation/API-Readiness-Checklist.md

@@ -5,7 +5,7 @@
 |  2 |API Implementation |   N        |                                             |
 | 3   |API Documentation  |   Y        |The API specification should include all the needed documentation.                                           |
 |4   |User Stories  |   Y        |	https://github.com/camaraproject/Commonalities/blob/main/documentation/Userstory-template.md                                            |
-| 5   |API test cases and documentation  |   Y        | A Gherkin feature file will be added to the main subproject repo and this will fulfill the minimum criteria of readiness w.r.t API test cases and documentation. If subprojects also intend to add test implementations, an aligned single implementation that is agreed amongst all provider implementors could be added to the main subproject repo. If no alignment is possible, each provider implementor will add the test implementation to their own repos   |
-| 6   |Tested by atleast 2 operators  |   Y        |                                             |
+| 5   |API test cases and documentation  |   Y        | A Gherkin feature file will be added to the main subproject repo and this will fulfil the minimum criteria of readiness w.r.t API test cases and documentation. If subprojects also intend to add test implementations, an aligned single implementation that is agreed amongst all provider implementors could be added to the main subproject repo. If no alignment is possible, each provider implementor will add the test implementation to their own repos   |
+| 6   |Tested by at least 2 operators  |   Y        |                                             |
 | 7   |Security review  |   Y        |  Spec contributions should include a security scheme section that complies with the AuthN&AuthZ techniques agreed in Commonalities.                                   |
 

documentation/Camara_Versioning_Guidelines.md

@@ -1,6 +1,6 @@
 # Camara subproject release guidelines
 
-* Release name for subprojects should be same as the tag-name for e.g. v0.8.0. The Github [release feature](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) should be used for this purpose. If referenced outside the subproject, it can be referred to as Release **\<sub-project-name>\<tag-name>** for eg. Release QualityOnDemand v0.8.0
+* Release name for subprojects should be same as the tag-name for e.g. v0.8.0. The GitHub [release feature](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository) should be used for this purpose. If referenced outside the subproject, it can be referred to as Release **\<sub-project-name>\<tag-name>** for e.g. Release QualityOnDemand v0.8.0
 * Every release includes the **CHANGELOG.md** file in the root directory of the subproject. Please make sure that the content is structured in a format that is easy to read. Please refer to the template provided here for possible sections that could be added to a changelog [CHANGELOG_TEMPLATE.md](./SupportingDocuments/CHANGELOG_TEMPLATE.md). Every release would add to the changelog. An example of how a changelog could look over time is shown below.
 * The release can be agreed within the subproject by making a pull request for the changelog. The merge of this pull request would be marked as the release commit and the text within the changelog would be used as the release description
 * Changelog content:
@@ -9,15 +9,15 @@
     * New features
     * Fixes
     * Deprecation (if any)
-* Going ahead, we could decide on a pull request process where use of right PR annotations could allow us to use tooling such as [krel](https://github.com/kubernetes/release/blob/master/docs/krel/README.md) or similar to automate atleast parts of release management. 
+* Going ahead, we could decide on a pull request process where use of right PR annotations could allow us to use tooling such as [krel](https://github.com/kubernetes/release/blob/master/docs/krel/README.md) or similar to automate at least parts of release management. 
 * Release branches should have naming convention **release-x.y.z**
 * Release tags should follow the naming conventions <strong>vx.y.z</strong> for versions
 * Adding relevant annotations to tags will be useful for later reference.
 * Provider implementation repos can have their own naming conventions with regard to branches, tags etc. It is however mandatory to provide as a part of the  CHANGELOG.md - the API release version, capabilities and changes that are a part of the respective provider implementation release.
 * Main branch is assumed to be the latest.
 * Camara subproject will have frequent updates to the main branch. There are no compatibility guarantees associated with code in any branch, including main, until it has been released. For example, changes may be reverted before a release is published. For the best results, use the latest published release of any given subproject within Camara.
 * The commonalities WG does not impose any restrictions on the subprojects for creating other branches, tags which might be needed/useful to address their specific requirements. The above said guidelines are only applicable for the subproject releases.
-* Main (`main`) branch and all release branches (`release\*`) will be protected by branch rules in Github: All pull requests need be reviewed by at least one code owner before they can be merged
+* Main (`main`) branch and all release branches (`release\*`) will be protected by branch rules in GitHub: All pull requests need to be reviewed by at least one code owner before they can be merged
 
 ### Release branches
 <img src="./images/versioning-pic.png" alt="Ver"

documentation/Issue and PR template Howto.md

@@ -2,7 +2,7 @@
 
 ## Introduction
 
-Github enables using templates in order to customize and standardize the information contributors 
+GitHub enables using templates in order to customize and standardize the information contributors 
 include when they open issues and pull requests in the repository.
 The proposed set of templates is adjusted to be applicable mainly to CAMARA API specification subprojects.
 
@@ -32,8 +32,8 @@ blank_issues_enabled: true
     about: Please ask and answer questions here.
  ```
 3. Modify Issue and PR templates in Markdown files included in the  `.github` folder if needed.
-* Issue templates include headers, where the name and descripttion of issue category, the suggested title of the issue, 
-the labels and assigness for the issue can be configured, e.g. 
+* Issue templates include headers, where the name and description of issue category, the suggested title of the issue, 
+the labels and assignees for the issue can be configured, e.g. 
 
 ```
 ---

documentation/MeetingMinutes/MoM-05-10-2023.md

@@ -0,0 +1,54 @@
+*Commonalities Meeting Minutes, 5th October 2023*
+
+## Attendees
+
+| Name | Company |
+| ---- | ------- |
+| Eric Murray | Vodafone |
+| Kevin Smith | Vodafone |
+| Ludovic Robert | Orange |
+| Murat Karabulut | TMUS |
+| Shilpa Padgaonkar|  Deutsche Telekom |
+| Rafal Artych | Deutsche Telekom |
+| Toshi Wakayama| KDDI |
+| Tanja de Groot | Nokia | 
+| Rajat Kondoi | Ericsson |
+| Foo Ming Hui | SingTel |
+
+## Agenda
+
+* **Review of issues and PRs**
+* **AOB**
+
+## Discussion
+| Agenda Item | Description |
+| ----------- | ----------- |
+| PR [#43](https://github.com/camaraproject/Commonalities/pull/43) | **Event Notification using CloudEvents specification**<br> OAS file needs to be updated to implement changes in API Design Guidelines related to CloudEvents|
+| PR [#57](https://github.com/camaraproject/Commonalities/pull/57) Issues<br> [#53](https://github.com/camaraproject/Commonalities/issues/53) [#46](https://github.com/camaraproject/Commonalities/issues/46)| **Unification of scopes, security and securitySchemes in CAMARA**<br> While the [IdentityAndConsentManagement Issue#57](https://github.com/camaraproject/IdentityAndConsentManagement/issues/57) is open the PR is stopped. |
+|Issue<br> [#67](https://github.com/camaraproject/Commonalities/issues/67)|**Consolidation Issue for open points release management** <br> Per request of TSC this issue consolidates a number of issues related to Release management (with [release-management](https://github.com/camaraproject/Commonalities/issues?q=is%3Aissue+is%3Aopen+label%3Arelease-management) label). All interested participants from Commonalities and other subprojects are asked to nominate themself as a contributor or as a reviewer in this issue. During next TSC meeting the work will be structured to address linked issues.|
+|   Issue<br> [#65](https://github.com/camaraproject/Commonalities/issues/65)     |  **Corrections of API-design-guidelines.md formating and typos**<br> PR should be prepared|
+|   Issue<br> [#59](https://github.com/camaraproject/Commonalities/issues/59)     |  **Location of API test definitions**<br> PR in Lead Template Repository will be merged |
+|  Issue<br> [#10](https://github.com/camaraproject/Commonalities/issues/10)        | **Filtering results** <br>  PR should be prepared      | 
+|Issue<br> [#15](https://github.com/camaraproject/Commonalities/issues/15) |  **CAMARA API linting ruleset** <br> Discussion is ongoing in the issue. The draft PR with Spectral built-in ["oas" ruleset](https://meta.stoplight.io/docs/spectral/4dec24461f3af-open-api-rules) and proposed new rules will be submitted by the end of the next week. |
+|  Issue<br> [#18](https://github.com/camaraproject/Commonalities/issues/18)        | **Require used (SI) unit to be specified for data definitions** <br>  The issues can be closed| 
+
+## Issues that can be closed 
+
+Issue [#59](https://github.com/camaraproject/Commonalities/issues/59)   **Location of API test definitions**<br> 
+Issue [#58](https://github.com/camaraproject/Commonalities/issues/58)    **Termination of mobile subscription in relation to notification**<br>
+Issue [#18](https://github.com/camaraproject/Commonalities/issues/18)    **Require used (SI) unit to be specified for data definitions** <br>
+
+## PRs that can be merged
+
+
+
+
+
+
+## AOB
+Next meeting is shifted to 16th of October (the same time).
+
+#### Reminder
+In order to be active contributor to the Commonalities subproject the subscribtion to the mailing list is needed - please visit https://lists.camaraproject.org/g/sp-com.
+
+Then the invitation to the Commonalities subproject Github repository will be send to the subscribed e-mail address.

documentation/MeetingMinutes/MoM-16-10-2023.md

@@ -0,0 +1,51 @@
+*Commonalities Meeting Minutes, 16th October 2023*
+
+## Attendees
+
+| Name | Company |
+| ---- | ------- |
+| Eric Murray | Vodafone |
+| Kevin Smith | Vodafone |
+| Ludovic Robert | Orange |
+| Patrice Conil | Orange |
+| Rubén Barrado Gonzalez | Telefonica|
+| Pierre Close | ATT |
+| Murat Karabulut | TMUS |
+| Ravindra Palaskar | Deutsche Telekom |
+| Rafal Artych | Deutsche Telekom |
+| Toshi Wakayama| KDDI |
+| Tanja de Groot | Nokia | 
+| Rajesh Mhatre | Starhub | 
+
+## Agenda
+
+* **Review of issues and PRs**
+* **AOB**
+
+## Discussion
+| Agenda Item | Description |
+| ----------- | ----------- |
+| PR [#43](https://github.com/camaraproject/Commonalities/pull/43) | **Event Notification using CloudEvents specification**<br> new comments indicating needed changes have beed added. The changes will be introduced before the next call. |
+| PR [#57](https://github.com/camaraproject/Commonalities/pull/57) Issues<br> [#53](https://github.com/camaraproject/Commonalities/issues/53) [#46](https://github.com/camaraproject/Commonalities/issues/46)| **Unification of scopes, security and securitySchemes in CAMARA**<br> While the [IdentityAndConsentManagement Issue#57](https://github.com/camaraproject/IdentityAndConsentManagement/issues/57) is open the PR is still stopped. |
+| PR [#73](https://github.com/camaraproject/Commonalities/pull/73) <br> Issue <br> [#70](https://github.com/camaraproject/Commonalities/issues/70)| **Improve discovery of Commonalties output documents by API Subprojects**<br> Editorial changes in the PR proposed. Further review needed.|
+|   Issue<br> [#65](https://github.com/camaraproject/Commonalities/issues/65)     |  **Corrections of API-design-guidelines.md formating and typos**<br> PR expected|
+|  Issue<br> [#42](https://github.com/camaraproject/Commonalities/issues/42)        | **Usage of ClassName in Mappings section of discriminator**  <br>  PR will be prepared before the next call. | 
+|  Issue<br> [#10](https://github.com/camaraproject/Commonalities/issues/10)        | **Filtering results** <br>  PR will be prepared before the next call.  | 
+|PR [#74](https://github.com/camaraproject/Commonalities/pull/74) <br> Issues <br>  [#15](https://github.com/camaraproject/Commonalities/issues/15) [#76](https://github.com/camaraproject/Commonalities/issues/76)|  **CAMARA API linting ruleset** <br> The draft PR will be changed to ready for review. In Issue [#76](https://github.com/camaraproject/Commonalities/issues/76) the severity of linting rules is discussed: `Error` level  forces the author to introduce changes, while `warning` can be left without reaction. The integration of ruleset with Github Actions was presented. More comments on proposed rules and proposals of rules to be added to the ruleset are expected. |
+
+
+## Issues waiting for End User Council opinion 
+
+Issues labeled with `EUC-question` label: <br> Issue [#44](https://github.com/camaraproject/Commonalities/issues/44)   **API Design for "Resource-based subscription"**<br> 
+Issue [#31](https://github.com/camaraproject/Commonalities/issues/31)   **RFC 7807 error responses to allow API consumers to be reminded of the API definition**<br>
+
+## Issues that can be closed 
+
+
+
+## PRs that can be merged
+
+
+
+## AOB
+Next meeting is on 30th of October.

documentation/UE-Identification.md

@@ -21,7 +21,7 @@ This document provides an overview and discusses the methods that a 5G Core netw
 
 A number of CAMARA APIs require the API invoker to identify the UE. The API invoker may have different UE identifiers, for example, a GPSI, in any of its various formats or perhaps the IP or MAC address of the UE. While the GPSI and the MAC address of the UE are permanent identifiers, the UE IP address is temporarily allocated to the UE, might be NATted, and may change during the lifetime of the session towards the application server. 
 
-Identifying a UE is not the same as identifying the PDU session that might be related to an API invocation. For example, a UE might have established several PDU sessions, each one on a different connectivity service (e.g., differnet S-NSSAI or DNN). As a result, the UE might be provisioned with different IP addresses for each PDU session. In cases where the UE is assumed to have established a single PDU session, or where it is possible to correlate the the API invoker to a connectivity service, the combination of it and the UE identification might be sufficient to identify one out of multiple PDU sessions as well.
+Identifying a UE is not the same as identifying the PDU session that might be related to an API invocation. For example, a UE might have established several PDU sessions, each one on a different connectivity service (e.g., differnet S-NSSAI or DNN). As a result, the UE might be provisioned with different IP addresses for each PDU session. In cases where the UE is assumed to have established a single PDU session, or where it is possible to correlate the API invoker to a connectivity service, the combination of it and the UE identification might be sufficient to identify one out of multiple PDU sessions as well.
 
 This document analizes the identifiers at the disposal of the API invoker for identifying a UE and proposes that CAMARA APIs, where possible, enable the UE identification accordingly.