Align with Commonalities r3.3 and ICM r3.3

code/API_definitions/network-slice-booking.yaml

@@ -147,7 +147,7 @@ paths:
         "404":
           $ref: "#/components/responses/Generic404"
         "429":
-          $ref: "#/components/responses/Generic429_requests"
+          $ref: "#/components/responses/Generic429"
 
     get:
       tags:
@@ -192,7 +192,7 @@ paths:
         "404":
           $ref: "#/components/responses/Generic404"
         "429":
-          $ref: "#/components/responses/Generic429_requests"
+          $ref: "#/components/responses/Generic429"
 
 components:
   securitySchemes:
@@ -300,7 +300,7 @@ components:
 
 
     Duration:
-      description: Specification of duration
+      description: Specification of duration. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#appendix-A) for duration.
       type: object
       properties:
         value:
@@ -364,16 +364,15 @@ components:
         startDate:
           type: string
           format: date-time
-          description: An instant of time, starting of the TimePeriod. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ
+          description: An instant of time, starting of the TimePeriod. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
           example: "2024-06-01T12:00:00Z"
         endDate:
           type: string
           format: date-time
-          description: An instant of time, ending of the TimePeriod. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ
+          description: An instant of time, ending of the TimePeriod. If not included, then the period has no ending date. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone.
           example: "2024-06-02T12:00:00Z"
       required:
         - startDate
-        - endDate
 
     Area:
       description: Base schema for all areas
@@ -672,32 +671,6 @@ components:
                 code: TOO_MANY_REQUESTS
                 message: Rate limit reached.
 
-    Generic429_requests:
-      description: Too Many Requests
-      headers:
-        x-correlator:
-          $ref: "#/components/headers/x-correlator"
-      content:
-        application/json:
-          schema:
-            allOf:
-              - $ref: "#/components/schemas/ErrorInfo"
-              - type: object
-                properties:
-                  status:
-                    enum:
-                      - 429
-                  code:
-                    enum:
-                      - TOO_MANY_REQUESTS
-          examples:
-            GENERIC_429_TOO_MANY_REQUESTS:
-              description: Access to the API has been temporarily blocked due to rate or spike arrest limits being reached
-              value:
-                status: 429
-                code: TOO_MANY_REQUESTS
-                message: Rate limit reached.
-
   examples:
     RETRIEVAL_CIRCLE:
       value:

documentation/MeetingMinutes/MOM-2025-07-04.md

@@ -0,0 +1,41 @@
+# CAMARA Network Slice Booking Meeting - MOM-2025-07-04
+
+
+*Friday, July 4th, 2025*
+
+
+## Attendees 
+* Xunli Yang (Huawei)
+* Xiao Dongrui (China Unicom)
+* Rafal Artych (DT)
+* Masaharu Hattori (KDDI)
+* Veerat Kulkarni
+
+
+
+
+## Agenda
+* Introduce the current progress of API Release and the next plan
+* PR#59 discussion -  add some developer-friendly API description, make some general terminology adjustments.
+* Free discussion 
+* AOB
+
+
+## Issues Discussions
+* PR#59 discussion 
+  * Add some developer-friendly API description in yaml file.
+  * Unified the terminology for the defined QoSProfile parameters to align with QoD.
+  * Ready for the API release-candidate version.
+* Free discussion - Business Model for Sclice Booking   
+  * If there is a new infrastructure needs to be spawned up for the specific network slice booking instance, what is the price model for the specific slice?
+  * Action: This issue can be further discussed in detail after the meeting through email or issue channels.
+
+## Timeline
+* Need to follow up with CAMARA release management.
+* Merge PR#54, and release API release candidate version r1.1.  
+
+## AOB
+1. The next call will be on Friday, 18th July, 16:00 CST / 10:00 CET
+
+
+

documentation/MeetingMinutes/MOM-2025-07-18.md

@@ -0,0 +1,50 @@
+# CAMARA Network Slice Booking Meeting - MOM-2025-07-018
+
+
+*Friday, July 18th, 2025*
+
+
+## Attendees 
+* Xunli Yang (Huawei)
+* Xiao Dongrui (China Unicom)
+* Masaharu Hattori (KDDI)
+* Surajj Jaggernath (Vodafone)
+
+
+
+
+## Agenda
+* Introduce the current progress of API Release and the next plan
+* Issue#63 discussion -  Naming pattern correction.
+* Issue#64 discussion -  Supplemental description fields for the API endpoints.
+* Issue#65 discussion -  Modify the name for schema QosProfile to avoid confusions.
+* Free discussion 
+* AOB
+
+
+## Issues Discussions
+* Issue#63 discussion 
+  * Property and similar names should follow lowerCamelCase naming pattern
+  * Schema names follow UpperCamelCase naming pattern
+* Issue#64 discussion
+  * Post: Add description field to help the developers understand the endpoint API better.
+  * Delete: Ideally this should have some explanation about delete usage e.g. what is the effect of deleting the session befor the endtime that is was booked for, etc.
+  * Get: The description may contain more details about the provided resource information that is returned when calling this end-point.
+* Issue#65 discussion
+* Modify the name for schema QosProfile to avoid confusions.
+  * There is already a definition for QosProfile within the API qos-profiles in QualityOnDemand which is different from the definition here (as defined as profile for one device).
+  * Consider to modify the name for the profile which is specific for NetworkSliceBooking to avoid confusions.
+  * Action: decided on the name `SliceQosProfile`.
+* Free discussion    
+  * The plan for the API of managing device access.
+  * Plan to release this part of API in the next release(Spring26).
+
+## Timeline
+* Need to follow up with CAMARA release management.
+* Merge PR#54, and release API release candidate version r1.1.  
+
+## AOB
+1. The next call will be on Friday, 1st Aug, 16:00 CST / 10:00 CET
+
+
+