@itentialopensource/adapter-etsi_sol002 0.2.0 → 0.3.0

package/report/adapter-openapi.yaml

@@ -0,0 +1,2548 @@
+openapi: 3.0.0
+info:
+  title: SOL002 - VNF Configuration interface
+  description: >
+    SOL002 - VNF Configuration Interface IMPORTANT: Please note that this file might be not aligned to the current
+
+    version of the ETSI Group Specification it refers to and has not been approved by the ETSI NFV ISG. In case of
+
+    discrepancies the published ETSI Group Specification takes precedence.
+
+    Please report bugs to https://forge.etsi.org/rep/nfv/SOL002-SOL003/issues
+  contact:
+    name: NFV-SOL WG
+  version: '1.2.0-impl:etsi.org:ETSI_NFV_OpenAPI:1'
+servers:
+- url: http://127.0.0.1/vnfconfig/v1
+  variables: {}
+- url: https://127.0.0.1/vnfconfig/v1
+  variables: {}
+paths:
+  /api_versions:
+    get:
+      summary: Retrieve API version information
+      description: >
+        The GET method reads API version information. This method shall follow the provisions specified in table 4.6.3.3.3.2-1 for request and response data structures, and response codes. URI query parameters are not supported.
+      operationId: RetrieveAPIversioninformation
+      parameters:
+      - name: Version
+        in: header
+        description: Version of the API requested to use when responding to this request.
+        required: true
+        style: simple
+        schema:
+          type: string
+      responses:
+        '200':
+          description: >-
+            200 OK
+
+            API version information was read successfully. The response body shall contain 4.4 API version information, as defined in clause 4.4.1.13.
+          headers:
+            Version:
+              description: The used API version.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: The used API version.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersionsResponse'
+                - description: >
+                    This type represents API version information.
+        '400':
+          description: >-
+            400 BAD REQUEST
+
+            400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned.
+
+            If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
+
+            If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
+
+            The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions400Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '401':
+          description: >-
+            401 UNAUTHORIZED
+
+            If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions401Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '403':
+          description: >-
+            403 FORBIDDEN
+
+            If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions403Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '404':
+          description: >-
+            404 NOT FOUND
+
+            If the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
+
+            This response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions404Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '405':
+          description: >-
+            405 METHOD NOT ALLOWED
+
+            If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions405Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '406':
+          description: >-
+            406 NOT ACCEPTABLE
+
+            If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions406Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '413':
+          description: >-
+            413 PAYLOAD TOO LARGE
+
+            If the payload body of a request is larger than the amount of data the API producer is willing or able to process, it shall respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for closing the connection. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions413Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '414':
+          description: >-
+            414 URI TOO LONG
+
+            If the request URI of a request is longer than the API producer is willing or able to process, it shall respond with this response code. This condition can e.g. be caused by passing long queries in the request URI of a GET request. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions414Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '416':
+          description: 416 Range Not Satisfiable
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions416Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '422':
+          description: >-
+            422 UNPROCESSABLE ENTITY
+
+            If the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            This error response code is only applicable for methods that have a request body.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions422Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '429':
+          description: >-
+            429 TOO MANY REQUESTS
+
+            If the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition ("rate limiting"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the "Retry-After" HTTP header. The "ProblemDetails" structure shall be provided and shall include in the "detail" attribute more information about the source of the problem.
+
+            The period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions429Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '500':
+          description: >-
+            500 INTERNAL SERVER ERROR
+
+            If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions500Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '503':
+          description: >-
+            503 SERVICE UNAVAILABLE
+
+            If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions503Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '504':
+          description: >-
+            504 GATEWAY TIMEOUT
+
+            If the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/ApiVersions504Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+      deprecated: false
+  /configuration:
+    get:
+      summary: Read VNF/VNFC configuration from VNF
+      description: >
+        The client can use this method to read configuration information about a VNF instance and/or its VNFC instances.
+      operationId: ReadVNF/VNFCconfigurationfromVNF
+      parameters:
+      - name: Version
+        in: header
+        description: Version of the API requested to use when responding to this request.
+        required: true
+        style: simple
+        schema:
+          type: string
+      - name: Authorization
+        in: header
+        description: 'The authorization token for the request. Reference: IETF RFC 7235.'
+        style: simple
+        schema:
+          type: string
+      responses:
+        '200':
+          description: >-
+            200 OK
+
+            Shall be returned when configuration information about a VNF instance  has been read successfully. The response
+
+            body shall contain a representation of the configuration resource.
+          headers:
+            Version:
+              description: The used API version.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: The used API version.
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the
+
+                corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the
+
+                      corresponding HTTP request has provided an invalid authorization token.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration.Get'
+                - description: >
+                    This type represents configuration parameters of a VNF instance and its VNFC instances.
+        '400':
+          description: >-
+            400 BAD REQUEST
+
+            400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned.
+
+            If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
+
+            If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
+
+            The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration400Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '401':
+          description: >-
+            401 UNAUTHORIZED
+
+            If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration401Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '403':
+          description: >-
+            403 FORBIDDEN
+
+            If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration403Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '404':
+          description: >-
+            404 NOT FOUND
+
+            If the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
+
+            This response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration404Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '405':
+          description: >-
+            405 METHOD NOT ALLOWED
+
+            If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration405Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '406':
+          description: >-
+            406 NOT ACCEPTABLE
+
+            If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration406Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '422':
+          description: >-
+            422 UNPROCESSABLE ENTITY
+
+            If the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            This error response code is only applicable for methods that have a request body.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration422Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '429':
+          description: >-
+            429 TOO MANY REQUESTS
+
+            If the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition ("rate limiting"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the "Retry-After" HTTP header. The "ProblemDetails" structure shall be provided and shall include in the "detail" attribute more information about the source of the problem.
+
+            The period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration429Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '500':
+          description: >-
+            500 INTERNAL SERVER ERROR
+
+            If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration500Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '503':
+          description: >-
+            503 SERVICE UNAVAILABLE
+
+            If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration503Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '504':
+          description: >-
+            504 GATEWAY TIMEOUT
+
+            If the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration504Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+      deprecated: false
+    patch:
+      summary: Modify VNF/VNFC configuration.
+      description: This method sets or modifies a configuration resource.
+      operationId: ModifyVNF/VNFCconfiguration.
+      parameters:
+      - name: Version
+        in: header
+        description: Version of the API requested to use when responding to this request.
+        required: true
+        style: simple
+        schema:
+          type: string
+      - name: Authorization
+        in: header
+        description: 'The authorization token for the request. Reference: IETF RFC 7235.'
+        style: simple
+        schema:
+          type: string
+      requestBody:
+        description: The parameter for the configuration modification, as defined in clause 9.5.2.2.
+        content:
+          application/json:
+            schema:
+              anyOf:
+              - $ref: '#/components/schemas/ConfigurationRequest'
+              - $ref: '#/components/schemas/ConfigurationRequest1'
+              description: The parameter for the configuration modification, as defined in clause 9.5.2.2.
+        required: true
+      responses:
+        '200':
+          description: >-
+            200 OK
+
+            Shall be returned when the request has been accepted and completed.  The response body shall contain the
+
+            parameters of the configuration  modification that was applied to the configuration resource.
+          headers:
+            Version:
+              description: The used API version.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: The used API version.
+          content:
+            application/json:
+              schema:
+                anyOf:
+                - $ref: '#/components/schemas/Configuration.Patch'
+                - $ref: '#/components/schemas/Configuration.Patch1'
+                description: >
+                  This type represents request parameters for the "Set Configuration" operation.
+                    * NOTE 1: At least one of "vnfConfigurationData" and "vnfcConfigurationData"
+                              shall be present.
+                    * NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration
+                              of existing VNFC instances.
+        '400':
+          description: >-
+            400 BAD REQUEST
+
+            400 code can be returned in the following specified cases, the specific cause has to be proper specified in the "ProblemDetails" structure to be returned.
+
+            If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or the payload body contains a syntactically incorrect data structure), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            If the response to a GET request which queries a container resource would be so big that the performance of the API producer is adversely affected, and the API producer does not support paging for the affected resource, it shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
+
+            If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
+
+            The use of this HTTP error response code described above is applicable to the use of the OAuth 2.0 for the authorization of API requests and notifications, as defined in clauses 4.5.3.3 and 4.5.3.4.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration400Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '401':
+          description: >-
+            401 UNAUTHORIZED
+
+            If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration401Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '403':
+          description: >-
+            403 FORBIDDEN
+
+            If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration403Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '404':
+          description: >-
+            404 NOT FOUND
+
+            If the API producer did not find a current representation for the resource addressed by the URI passed in the request or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
+
+            This response code is not appropriate in case the resource addressed by the URI is a container resource which is designed to contain child resources, but does not contain any child resource at the time the request is received. For a GET request to an existing empty container resource, a typical response contains a 200 OK response code and a payload body with an empty array.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration404Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '405':
+          description: >-
+            405 METHOD NOT ALLOWED
+
+            If a particular HTTP method is not supported for a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration405Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '406':
+          description: >-
+            406 NOT ACCEPTABLE
+
+            If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration406Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '412':
+          description: >-
+            412 PRECONDITION FAILED
+
+            Error: A precondition given in an HTTP request header is not fulfilled. Typically, this is due to an ETag mismatch, indicating that the resource was modified by another entity. The response body should contain a ProblemDetails structure, in which the "detail" attribute should convey more information about the error.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration412Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '416':
+          description: 416 Range Not Satisfiable
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration416Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '422':
+          description: >-
+            422 UNPROCESSABLE ENTITY
+
+            If the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
+
+            This error response code is only applicable for methods that have a request body.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration422Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '429':
+          description: >-
+            429 TOO MANY REQUESTS
+
+            If the API consumer has sent too many requests in a defined period of time and the API producer is able to detect that condition ("rate limiting"), the API producer shall respond with this response code, following the provisions in IETF RFC 6585 [17] for the use of the "Retry-After" HTTP header. The "ProblemDetails" structure shall be provided and shall include in the "detail" attribute more information about the source of the problem.
+
+            The period of time and allowed number of requests are configured within the API producer by means outside the scope of the present document.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration429Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '500':
+          description: >-
+            500 INTERNAL SERVER ERROR
+
+            If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration500Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '503':
+          description: >-
+            503 SERVICE UNAVAILABLE
+
+            If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration503Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+        '504':
+          description: >-
+            504 GATEWAY TIMEOUT
+
+            If the API producer encounters a timeout while waiting for a response from an upstream server (i.e. a server that the API producer communicates with when fulfilling a request), it should respond with this response code.
+          headers:
+            WWW-Authenticate:
+              description: >
+                Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
+            Version:
+              description: >
+                Version of the API used in the response.
+              content:
+                text/plain:
+                  schema:
+                    type: string
+                    description: >
+                      Version of the API used in the response.
+          content:
+            application/json:
+              schema:
+                allOf:
+                - $ref: '#/components/schemas/Configuration504Error1'
+                - description: >
+                    The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+      deprecated: false
+components:
+  schemas:
+    ApiVersionsResponse:
+      title: ApiVersionsResponse
+      required:
+      - uriPrefix
+      - apiVersions
+      type: object
+      properties:
+        uriPrefix:
+          type: string
+          description: Specifies the URI prefix for the API, in the following form {apiRoot}/{apiName}/{apiMajorVersion}/.
+        apiVersions:
+          type: array
+          items:
+            $ref: '#/components/schemas/ApiVersion'
+          description: Version(s) supported for the API signaled by the uriPrefix attribute.
+      description: This type represents API version information.
+    ApiVersion:
+      title: ApiVersion
+      required:
+      - version
+      type: object
+      properties:
+        version:
+          type: string
+          description: Identifies a supported version. The value of the version attribute shall be a version identifier as specified in clause 9.1 (SOL013).
+        isDeprecated:
+          type: boolean
+          description: >-
+            If such information is available, this attribute indicates whether use of the version signaled by the version attribute is deprecated (true) or not (false).
+
+            A deprecated version is still supported by the API producer but is recommended not to be used any longer. When a version is no longer supported, it does not appear in the response body.
+        retirementDate:
+          type: string
+          description: 'Date-time stamp. Representation: String formatted according to IETF RFC 3339.'
+          format: date-time
+    ApiVersions400Error1:
+      title: ApiVersions400Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions401Error1:
+      title: ApiVersions401Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions403Error1:
+      title: ApiVersions403Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions404Error1:
+      title: ApiVersions404Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions405Error1:
+      title: ApiVersions405Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions406Error1:
+      title: ApiVersions406Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions413Error1:
+      title: ApiVersions413Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions414Error1:
+      title: ApiVersions414Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions416Error1:
+      title: ApiVersions416Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions422Error1:
+      title: ApiVersions422Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions429Error1:
+      title: ApiVersions429Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions500Error1:
+      title: ApiVersions500Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions503Error1:
+      title: ApiVersions503Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ApiVersions504Error1:
+      title: ApiVersions504Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration.Get:
+      title: Configuration.Get
+      required:
+      - vnfConfigurationData
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: Configuration parameters of the VNFC instances.
+      description: This type represents configuration parameters of a VNF instance and its VNFC instances.
+    VnfConfigurationData:
+      title: VnfConfigurationData
+      type: object
+      properties:
+        extCpConfig:
+          type: array
+          items:
+            $ref: '#/components/schemas/ExtCpConfig'
+          description: Configuration parameters for the external CPs of the VNF instance.
+        dhcpServer:
+          type: string
+          description: 'An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.'
+        vnfSpecificData:
+          type: object
+          description: This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type.
+      description: This type represents configuration parameters of a VNF instance.
+    ExtCpConfig:
+      title: ExtCpConfig
+      required:
+      - cpId
+      - cpdId
+      - addresses
+      type: object
+      properties:
+        cpId:
+          type: string
+          description: An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
+        cpdId:
+          type: string
+          description: An identifier that is unique within a VNF descriptor.
+        addresses:
+          type: array
+          items:
+            oneOf:
+            - $ref: '#/components/schemas/Address3'
+            - $ref: '#/components/schemas/Address4'
+            anyOf:
+            - $ref: '#/components/schemas/Address'
+            - $ref: '#/components/schemas/Address'
+          description: Network address and port assigned to the CP.
+      description: This type represents configuration parameters of a CP instance.
+    Address:
+      title: Address
+      type: object
+      properties:
+        address:
+          allOf:
+          - $ref: '#/components/schemas/Address1'
+          - description: Network address that has been configured on the CP. See NOTE 1.
+        useDynamicAddress:
+          type: boolean
+          description: Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.
+        port:
+          type: integer
+          description: The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).
+          format: int32
+    Address1:
+      title: Address1
+      type: object
+      properties:
+        macAddress:
+          type: string
+          description: 'A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.'
+        ipAddress:
+          type: string
+          description: 'An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.'
+      description: Network address that has been configured on the CP. See NOTE 1.
+    Address3:
+      title: Address3
+      required:
+      - address
+      type: object
+      properties:
+        address:
+          allOf:
+          - $ref: '#/components/schemas/Address1'
+          - description: Network address that has been configured on the CP. See NOTE 1.
+        useDynamicAddress:
+          type: boolean
+          description: Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.
+        port:
+          type: integer
+          description: The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).
+          format: int32
+    Address4:
+      title: Address4
+      required:
+      - useDynamicAddress
+      type: object
+      properties:
+        address:
+          allOf:
+          - $ref: '#/components/schemas/Address1'
+          - description: Network address that has been configured on the CP. See NOTE 1.
+        useDynamicAddress:
+          type: boolean
+          description: Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.
+        port:
+          type: integer
+          description: The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).
+          format: int32
+    Address5:
+      title: Address5
+      type: object
+      properties:
+        address:
+          allOf:
+          - $ref: '#/components/schemas/Address1'
+          - description: Network address that has been configured on the CP. See NOTE 1.
+        useDynamicAddress:
+          type: boolean
+          description: Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.
+        port:
+          type: integer
+          description: The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).
+          format: int32
+      description: >-
+        This type represents configuration parameters of a CP instance address.
+           *  NOTE 1: Either "address" or "useDynamicAddress" shall be present.
+           *  NOTE 2: At least one of "macAddress" and "ipAddress" shall be present.
+    VnfcConfigurationDatum:
+      title: VnfcConfigurationDatum
+      required:
+      - vnfcInstanceId
+      type: object
+      properties:
+        vnfcInstanceId:
+          type: string
+          description: An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
+        intCpConfig:
+          type: array
+          items:
+            $ref: '#/components/schemas/IntCpConfig'
+          description: Configuration parameters for the internal CPs of the VNFC instance.
+        dhcpServer:
+          type: string
+          description: 'An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.'
+        vnfcSpecificData:
+          type: object
+          description: This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of keyvalue pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 8259. In the following example, a list of key-value pairs with four keys ("aString", "aNumber", "anArray" and "anObject") is provided to illustrate that the values associated with different keys can be of different type.
+      description: This type represents configuration parameters of a VNFC instance.
+    IntCpConfig:
+      title: IntCpConfig
+      required:
+      - cpId
+      - cpdId
+      - addresses
+      type: object
+      properties:
+        cpId:
+          type: string
+          description: An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
+        cpdId:
+          type: string
+          description: An identifier that is unique within a VNF descriptor.
+        addresses:
+          type: array
+          items:
+            oneOf:
+            - $ref: '#/components/schemas/Address3'
+            - $ref: '#/components/schemas/Address4'
+            anyOf:
+            - $ref: '#/components/schemas/Address'
+            - $ref: '#/components/schemas/Address'
+          description: Network address and port assigned to the CP.
+      description: This type represents configuration parameters of a CP instance.
+    Configuration400Error1:
+      title: Configuration400Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration401Error1:
+      title: Configuration401Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration403Error1:
+      title: Configuration403Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration404Error1:
+      title: Configuration404Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration405Error1:
+      title: Configuration405Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration406Error1:
+      title: Configuration406Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration422Error1:
+      title: Configuration422Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration429Error1:
+      title: Configuration429Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration500Error1:
+      title: Configuration500Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration503Error1:
+      title: Configuration503Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration504Error1:
+      title: Configuration504Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    ConfigurationRequest:
+      title: ConfigurationRequest
+      required:
+      - vnfConfigurationData
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: >-
+            Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the "vnfcConfigurationData" attribute shall follow these provisions:
+              Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
+                Assumptions:
+                  1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
+                     is the "VnfcConfigurationData" array that contains the changes.
+                  2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
+                  3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
+                     has the same content of the "vnfcInstanceId" attribute as the "newEntry";
+                     a "newEntry" has no corresponding entry if no such "oldEntry" exists.
+                  4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
+                     is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
+                Provisions:
+                  1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
+                     the "oldList" array shall be modified by adding that "newEntry".
+
+                  2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
+                     the value of "oldEntry" shall be updated with the value of "newEntry" according to
+                    the rules of JSON Merge PATCH (see IETF RFC 7396 ).
+        vnfcConfigurationDataDeleteIds:
+          type: array
+          items:
+            type: string
+          description: List of identifiers entries to be deleted from the 'vnfcConfigurationData" attribute array to be used as "deleteIdList" as defined below this table.
+    ConfigurationRequest1:
+      title: ConfigurationRequest1
+      required:
+      - vnfcConfigurationData
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: >-
+            Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the "vnfcConfigurationData" attribute shall follow these provisions:
+              Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
+                Assumptions:
+                  1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
+                     is the "VnfcConfigurationData" array that contains the changes.
+                  2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
+                  3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
+                     has the same content of the "vnfcInstanceId" attribute as the "newEntry";
+                     a "newEntry" has no corresponding entry if no such "oldEntry" exists.
+                  4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
+                     is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
+                Provisions:
+                  1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
+                     the "oldList" array shall be modified by adding that "newEntry".
+
+                  2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
+                     the value of "oldEntry" shall be updated with the value of "newEntry" according to
+                    the rules of JSON Merge PATCH (see IETF RFC 7396 ).
+        vnfcConfigurationDataDeleteIds:
+          type: array
+          items:
+            type: string
+          description: List of identifiers entries to be deleted from the 'vnfcConfigurationData" attribute array to be used as "deleteIdList" as defined below this table.
+    ConfigurationRequest2:
+      title: ConfigurationRequest2
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: >-
+            Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the "vnfcConfigurationData" attribute shall follow these provisions:
+              Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
+                Assumptions:
+                  1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
+                     is the "VnfcConfigurationData" array that contains the changes.
+                  2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
+                  3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
+                     has the same content of the "vnfcInstanceId" attribute as the "newEntry";
+                     a "newEntry" has no corresponding entry if no such "oldEntry" exists.
+                  4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
+                     is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
+                Provisions:
+                  1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
+                     the "oldList" array shall be modified by adding that "newEntry".
+
+                  2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
+                     the value of "oldEntry" shall be updated with the value of "newEntry" according to
+                    the rules of JSON Merge PATCH (see IETF RFC 7396 ).
+        vnfcConfigurationDataDeleteIds:
+          type: array
+          items:
+            type: string
+          description: List of identifiers entries to be deleted from the 'vnfcConfigurationData" attribute array to be used as "deleteIdList" as defined below this table.
+      description: >-
+        This type represents request parameters for the "Set Configuration" operation.
+          * NOTE 1: At least one of "vnfConfigurationData" and "vnfcConfigurationData"
+                    shall be present.
+          * NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration
+                    of existing VNFC instances.
+    Configuration.Patch:
+      title: Configuration.Patch
+      required:
+      - vnfConfigurationData
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: >-
+            Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the "vnfcConfigurationData" attribute shall follow these provisions:
+              Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
+                Assumptions:
+                  1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
+                     is the "VnfcConfigurationData" array that contains the changes.
+                  2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
+                  3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
+                     has the same content of the "vnfcInstanceId" attribute as the "newEntry";
+                     a "newEntry" has no corresponding entry if no such "oldEntry" exists.
+                  4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
+                     is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
+                Provisions:
+                  1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
+                     the "oldList" array shall be modified by adding that "newEntry".
+
+                  2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
+                     the value of "oldEntry" shall be updated with the value of "newEntry" according to
+                    the rules of JSON Merge PATCH (see IETF RFC 7396 ).
+        vnfcConfigurationDataDeleteIds:
+          type: array
+          items:
+            type: string
+          description: List of identifiers entries to be deleted from the 'vnfcConfigurationData" attribute array to be used as "deleteIdList" as defined below this table.
+    Configuration.Patch1:
+      title: Configuration.Patch1
+      required:
+      - vnfcConfigurationData
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: >-
+            Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the "vnfcConfigurationData" attribute shall follow these provisions:
+              Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
+                Assumptions:
+                  1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
+                     is the "VnfcConfigurationData" array that contains the changes.
+                  2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
+                  3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
+                     has the same content of the "vnfcInstanceId" attribute as the "newEntry";
+                     a "newEntry" has no corresponding entry if no such "oldEntry" exists.
+                  4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
+                     is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
+                Provisions:
+                  1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
+                     the "oldList" array shall be modified by adding that "newEntry".
+
+                  2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
+                     the value of "oldEntry" shall be updated with the value of "newEntry" according to
+                    the rules of JSON Merge PATCH (see IETF RFC 7396 ).
+        vnfcConfigurationDataDeleteIds:
+          type: array
+          items:
+            type: string
+          description: List of identifiers entries to be deleted from the 'vnfcConfigurationData" attribute array to be used as "deleteIdList" as defined below this table.
+    Configuration.Patch2:
+      title: Configuration.Patch2
+      type: object
+      properties:
+        vnfConfigurationData:
+          allOf:
+          - $ref: '#/components/schemas/VnfConfigurationData'
+          - description: This type represents configuration parameters of a VNF instance.
+        vnfcConfigurationData:
+          type: array
+          items:
+            $ref: '#/components/schemas/VnfcConfigurationDatum'
+          description: >-
+            Modifications to configuration data for certain VNFC instances. See NOTE 1 and NOTE 2. If present, the modifications of the "vnfcConfigurationData" attribute shall follow these provisions:
+              Modifying an attribute that is an array of objects of type "VnfcConfigurationData".
+                Assumptions:
+                  1) "oldList" is the "VnfcConfigurationData" array to be modified and "newList"
+                     is the "VnfcConfigurationData" array that contains the changes.
+                  2) "oldEntry" is an entry in "oldList" and "newEntry" is an entry in "newList".
+                  3) A "newEntry" has a "corresponding entry" if there exists an "oldEntry" that
+                     has the same content of the "vnfcInstanceId" attribute as the "newEntry";
+                     a "newEntry" has no corresponding entry if no such "oldEntry" exists.
+                  4) In any array of "VnfcConfigurationData" structures, the content of "vnfcInstanceId"
+                     is unique (i.e. there shall be no two entries with the same content of "vnfcInstanceId").
+                Provisions:
+                  1) For each "newEntry" in "newList" that has no corresponding entry in "oldList",
+                     the "oldList" array shall be modified by adding that "newEntry".
+
+                  2) For each "newEntry" in "newList" that has a corresponding "oldEntry" in "oldList",
+                     the value of "oldEntry" shall be updated with the value of "newEntry" according to
+                    the rules of JSON Merge PATCH (see IETF RFC 7396 ).
+        vnfcConfigurationDataDeleteIds:
+          type: array
+          items:
+            type: string
+          description: List of identifiers entries to be deleted from the 'vnfcConfigurationData" attribute array to be used as "deleteIdList" as defined below this table.
+      description: >-
+        This type represents request parameters for the "Set Configuration" operation.
+          * NOTE 1: At least one of "vnfConfigurationData" and "vnfcConfigurationData"
+                    shall be present.
+          * NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration
+                    of existing VNFC instances.
+    Configuration412Error1:
+      title: Configuration412Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration416Error:
+      title: Configuration416Error
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+    Configuration416Error1:
+      title: Configuration416Error1
+      required:
+      - status
+      - detail
+      type: object
+      properties:
+        type:
+          type: string
+          description: A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
+        title:
+          type: string
+          description: A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type.  It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
+        status:
+          type: integer
+          description: The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
+          format: int32
+        detail:
+          type: string
+          description: A human-readable explanation specific to this occurrence of the problem.
+        instance:
+          type: string
+          description: A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
+      description: >
+        The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
+tags: []
+externalDocs:
+  description: ETSI GS NFV-SOL 002 V3.3.1
+  url: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/03.03.01_60/gs_NFV-SOL002v030301p.pdf