From a7c562d937ba7c6427e1d4d45aa646cbf240f28f Mon Sep 17 00:00:00 2001
From: Giacomo Bernini <g.bernini@nextworks.it>
Date: Wed, 12 Dec 2018 18:17:24 +0100
Subject: [PATCH] readded missing SOL002 folder
---
.../VNFConfiguration-API/Configuration.robot | 91 +
SOL002/VNFConfiguration-API/README.md | 12 +
.../SOL002-VNFConfiguration-API.json | 1398 +++++++++++
.../SOL002-VNFConfiguration-API.yaml | 2202 +++++++++++++++++
.../jsons/vnfConfigModifications.json | 43 +
.../schemas/problemDetails.schema.json | 34 +
.../vnfConfigModifications.schema.json | 157 ++
.../schemas/vnfConfiguration.schema.json | 160 ++
SOL002/VNFConfiguration-API/variables.txt | 42 +
9 files changed, 4139 insertions(+)
create mode 100644 SOL002/VNFConfiguration-API/Configuration.robot
create mode 100644 SOL002/VNFConfiguration-API/README.md
create mode 100644 SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.json
create mode 100644 SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.yaml
create mode 100644 SOL002/VNFConfiguration-API/jsons/vnfConfigModifications.json
create mode 100644 SOL002/VNFConfiguration-API/schemas/problemDetails.schema.json
create mode 100644 SOL002/VNFConfiguration-API/schemas/vnfConfigModifications.schema.json
create mode 100644 SOL002/VNFConfiguration-API/schemas/vnfConfiguration.schema.json
create mode 100644 SOL002/VNFConfiguration-API/variables.txt
diff --git a/SOL002/VNFConfiguration-API/Configuration.robot b/SOL002/VNFConfiguration-API/Configuration.robot
new file mode 100644
index 00000000..05af12fe
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/Configuration.robot
@@ -0,0 +1,91 @@
+*** Settings ***
+Resource variables.txt
+Library REST ${VNF_SCHEMA}://${VNF_HOST}:${VNF_PORT}
+... spec=SOL002-VNFConfiguration-API.yaml
+Library JSONLibrary
+Library JSONSchemaLibrary schemas/
+Library OperatingSystem
+Library DependencyLibrary
+
+*** Variables ***
+${Etag}= an etag
+${Etag_modified}= a modified etag
+
+*** Test cases ***
+POST Configuration - Method not implemented
+ log Trying to perform a POST. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Post ${apiRoot}/${apiName}/${apiVersion}/configuration
+ Log Validate Status code
+ Integer response status 405
+
+Get information about a configuration
+ Log Query VNF The GET method queries information about a configuration.
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Log Execute Query and validate response
+ Get ${apiRoot}/${apiName}/${apiVersion}/configuration
+ ${Etag}= Output response headers Etag
+ Log Validate Status code
+ Integer response status 200
+ ${contentType}= Output response headers Content-Type
+ Should Contain ${contentType} ${CONTENT_TYPE}
+ ${result}= Output response body
+ ${json}= evaluate json.loads('''${result}''') json
+ Validate Json vnfConfiguration.schema.json ${json}
+ Log Validation OK
+
+PUT Config - Method not implemented
+ log Trying to perform a PUT. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Put ${apiRoot}/${apiName}/${apiVersion}/configuration
+ Log Validate Status code
+ Integer response status 405
+
+PATCH Config
+ log Trying to perform a PATCH. This method modifies the configuration
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ ${body}= Get File json/vnfConfigModifications.json
+ Patch ${apiRoot}/${apiName}/${apiVersion}/configuration ${body}
+ Log Validate Status code
+ ${Etag_modified}= Output response headers Etag
+ Integer response status 200
+ ${contentType}= Output response headers Content-Type
+ Should Contain ${contentType} ${CONTENT_TYPE}
+ ${result}= Output response body
+ ${json}= evaluate json.loads('''${result}''') json
+ Validate Json vnfConfigModifications.schema.json ${json}
+ Log Validation OK
+
+PATCH Config - Precondition failed
+ [Documentation] Precondition Failed
+ ... Precondition Failed 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.
+ Depends On Test PATCH Alarm # If the previous test scceeded, it means that Etag has been modified
+ log Trying to perform a PATCH. This method modifies an individual alarm resource
+ Set Headers {"Accept":"${ACCEPT}"}
+ Set Headers {"Content-Type": "${CONTENT_TYPE}"}
+ Set Headers {"If-Match": "${Etag}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ ${body}= Get File json/vnfConfigModifications.json
+ Patch ${apiRoot}/${apiName}/${apiVersion}/configuration ${body}
+ Log Validate Status code
+ Integer response status 412
+ ${problemDetails}= Output response body
+ ${json}= evaluate json.loads('''${problemDetails}''') json
+ Validate Json ProblemDetails.schema.json ${json}
+ Log Validation OK
+
+DELETE Config - Method not implemented
+ log Trying to perform a DELETE. This method should not be implemented
+ Set Headers {"Accept":"${ACCEPT}"}
+ Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"Authorization":"${AUTHORIZATION}"}
+ Delete ${apiRoot}/${apiName}/${apiVersion}/configuration
+ Log Validate Status code
+ Integer response status 405
\ No newline at end of file
diff --git a/SOL002/VNFConfiguration-API/README.md b/SOL002/VNFConfiguration-API/README.md
new file mode 100644
index 00000000..f5f7677f
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/README.md
@@ -0,0 +1,12 @@
+# NFV API Tests
+
+This is a development folder for ETSI STF 557.
+It includes the NFV API conformance test descriptions.
+
+## License
+
+Any software in this repository is released under the ETSI Software License.
+Licensing information is available in the attached LICENSE file.
+
+
+Copyright (c) ETSI 2018
diff --git a/SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.json b/SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.json
new file mode 100644
index 00000000..c324fdd7
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.json
@@ -0,0 +1,1398 @@
+{
+ "swagger": "2.0",
+ "info": {
+ "version": "1.1.1",
+ "title": "SOL002 - VNF Configuration interface",
+ "description": "VNF Configuration interface of ETSI NFV SOL002\n\nIMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.\n\nPlease report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=---\n",
+ "license": {
+ "name": "ETSI Forge copyright notice",
+ "url": "https://forge.etsi.org/etsi-forge-copyright-notice.txt"
+ }
+ },
+ "externalDocs": {
+ "description": "ETSI GS NFV-SOL 002 V2.4.1",
+ "url": "http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf"
+ },
+ "basePath": "/vnfconfig/v1",
+ "schemes": [
+ "http",
+ "https"
+ ],
+ "consumes": [
+ "application/json"
+ ],
+ "produces": [
+ "application/json"
+ ],
+ "paths": {
+ "/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.\n",
+ "responses": {
+ "200": {
+ "description": "OK\nConfiguration information about a VNF instance was read successfully. The response body shall contain a representation of the configuration resource.\n",
+ "schema": {
+ "$ref": "#/definitions/VnfConfiguration"
+ }
+ },
+ "400": {
+ "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), 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.\n ---\n\nIf 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.\n ---\n\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "Unauthorized\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "Forbidden\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "Method Not Allowed\nIf 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 in that case.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "Not Acceptable\nIf 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 in that case.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "409": {
+ "description": "Conflict\nAnother request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "Requested Range Not Satisfiable\nThis code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "422": {
+ "description": "Unprocessable Entity\nIf 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. NOTE 2: This error response code is only applicable for methods that have a request body.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "Internal Server Error\nIf 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 withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "Service Unavailable\nIf 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 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ },
+ "patch": {
+ "summary": "Modify VNF/VNFC configuration.",
+ "description": "This method sets or modifies a configuration resource.",
+ "parameters": [
+ {
+ "name": "configModifications",
+ "description": "The parameter for the configuration modification.",
+ "required": true,
+ "in": "body",
+ "schema": {
+ "$ref": "#/definitions/VnfConfigModifications"
+ }
+ }
+ ],
+ "responses": {
+ "200": {
+ "description": "OK\nThe request was accepted and completed. The response body shall contain the parameters of the configuration modification that was applied to the configuration resource.\n",
+ "schema": {
+ "$ref": "#/definitions/VnfConfigModifications"
+ }
+ },
+ "400": {
+ "description": "Bad Request\nIf the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), 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.\n ---\n\nIf 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.\n ---\n\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "401": {
+ "description": "Unauthorized\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ },
+ "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.\n",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 0
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "403": {
+ "description": "Forbidden\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "404": {
+ "description": "Not Found\nIf 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "405": {
+ "description": "Method Not Allowed\nIf 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 in that case.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "406": {
+ "description": "Not Acceptable\nIf 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 in that case.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "409": {
+ "description": "Conflict\nAnother request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "412": {
+ "description": "Precondition Failed\nA 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.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "416": {
+ "description": "Requested Range Not Satisfiable\nThis code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "422": {
+ "description": "Unprocessable Entity\nIf 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. NOTE 2: This error response code is only applicable for methods that have a request body.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "500": {
+ "description": "Internal Server Error\nIf 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 withthis response code. The \"ProblemDetails\" structure shall be provided, and shall include in the \"detail\" attribute more information about the source of the problem.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ },
+ "503": {
+ "description": "Service Unavailable\nIf 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 [13] for the use of the \"Retry-After\" HTTP header and for the alternative to refuse the connection. The \"ProblemDetails\" structure may be omitted.\n",
+ "headers": {
+ "Content-Type": {
+ "description": "The MIME type of the body of the response.",
+ "type": "string",
+ "maximum": 1,
+ "minimum": 1
+ }
+ },
+ "schema": {
+ "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].\n",
+ "type": "object",
+ "required": [
+ "status",
+ "detail"
+ ],
+ "properties": {
+ "type": {
+ "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\".\n",
+ "type": "string",
+ "format": "URI"
+ },
+ "title": {
+ "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).\n",
+ "type": "string"
+ },
+ "status": {
+ "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.\n",
+ "type": "integer"
+ },
+ "detail": {
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n",
+ "type": "string"
+ },
+ "instance": {
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "type": "string",
+ "format": "URI"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "definitions": {
+ "VnfConfiguration": {
+ "description": "This type represents configuration parameters of a VNF instance and its VNFC instances.\n",
+ "type": "object",
+ "required": [
+ "vnfConfigurationData"
+ ],
+ "properties": {
+ "vnfConfigurationData": {
+ "description": "This type represents configuration parameters of a VNF instance.\n",
+ "type": "object",
+ "properties": {
+ "extCpConfig": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ },
+ "vnfcConfigurationData": {
+ "description": "Configuration parameters of the VNFC instances.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a VNFC instance.\n",
+ "type": "object",
+ "required": [
+ "vnfcInstanceId"
+ ],
+ "properties": {
+ "vnfcInstanceId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "intCpConfig": {
+ "description": "Configuration parameters for the internal CPs of the VNFC instance.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfcSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ }
+ }
+ }
+ },
+ "VnfConfigModifications": {
+ "description": "This type represents request parameters for the \"Set Configuration\" operation. * NOTE 1: At least one of \"vnfConfigurationData\" and \"vnfcConfigurationData\"\n shall be present.\n * NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration\n of existing VNFC instances.\n",
+ "type": "object",
+ "properties": {
+ "vnfConfigurationData": {
+ "description": "This type represents configuration parameters of a VNF instance.\n",
+ "type": "object",
+ "properties": {
+ "extCpConfig": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ },
+ "vnfcConfigurationData": {
+ "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\".\n Assumptions:\n 1) \"oldList\" is the \"VnfcConfigurationData\" array to be modified and \"newList\"\n is the \"VnfcConfigurationData\" array that contains the changes.\n 2) \"oldEntry\" is an entry in \"oldList\" and \"newEntry\" is an entry in \"newList\".\n 3) A \"newEntry\" has a \"corresponding entry\" if there exists an \"oldEntry\" that \n has the same content of the \"vnfcInstanceId\" attribute as the \"newEntry\"; \n a \"newEntry\" has no corresponding entry if no such \"oldEntry\" exists.\n 4) In any array of \"VnfcConfigurationData\" structures, the content of \"vnfcInstanceId\"\n is unique (i.e. there shall be no two entries with the same content of \"vnfcInstanceId\").\n Provisions:\n 1) For each \"newEntry\" in \"newList\" that has no corresponding entry in \"oldList\", \n the \"oldList\" array shall be modified by adding that \"newEntry\".\n\n 2) For each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\",\n the value of \"oldEntry\" shall be updated with the value of \"newEntry\" according to\n the rules of JSON Merge PATCH (see IETF RFC 7396 ).\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a VNFC instance.\n",
+ "type": "object",
+ "required": [
+ "vnfcInstanceId"
+ ],
+ "properties": {
+ "vnfcInstanceId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "intCpConfig": {
+ "description": "Configuration parameters for the internal CPs of the VNFC instance.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfcSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ }
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.yaml b/SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.yaml
new file mode 100644
index 00000000..a1007e27
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/SOL002-VNFConfiguration-API.yaml
@@ -0,0 +1,2202 @@
+swagger: '2.0'
+info:
+ version: 1.1.1
+ title: SOL002 - VNF Configuration interface
+ description: >
+ VNF Configuration interface of ETSI NFV SOL002
+
+
+ IMPORTANT: Please note that this file might be not aligned to the current
+ version of the ETSI Group Specification it refers to. In case of
+ discrepancies the published ETSI Group Specification takes precedence.
+
+
+ Please report bugs to
+ https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=---
+ license:
+ name: ETSI Forge copyright notice
+ url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
+externalDocs:
+ description: ETSI GS NFV-SOL 002 V2.4.1
+ url: >-
+ http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.04.01_60/gs_NFV-SOL002v020401p.pdf
+basePath: /vnfconfig/v1
+schemes:
+ - http
+ - https
+consumes:
+ - application/json
+produces:
+ - application/json
+paths:
+ /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.
+ responses:
+ '200':
+ description: >
+ OK
+
+ Configuration information about a VNF instance was read
+ successfully. The response body shall contain a representation of
+ the configuration resource.
+ schema:
+ $ref: '#/definitions/VnfConfiguration'
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), 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 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.
+
+ ---
+
+ 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ 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:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ 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:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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 in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ 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 in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '409':
+ description: >
+ Conflict
+
+ Another request is in progress that prohibits the fulfilment of the
+ current request, or the current resource state is inconsistent with
+ the request.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '422':
+ description: >
+ 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. NOTE 2:
+ This error response code is only applicable for methods that have a
+ request body.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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 withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ patch:
+ summary: Modify VNF/VNFC configuration.
+ description: This method sets or modifies a configuration resource.
+ parameters:
+ - name: configModifications
+ description: The parameter for the configuration modification.
+ required: true
+ in: body
+ schema:
+ $ref: '#/definitions/VnfConfigModifications'
+ responses:
+ '200':
+ description: >
+ OK
+
+ The request was accepted and completed. The response body shall
+ contain the parameters of the configuration modification that was
+ applied to the configuration resource.
+ schema:
+ $ref: '#/definitions/VnfConfigModifications'
+ '400':
+ description: >
+ Bad Request
+
+ If the request is malformed or syntactically incorrect (e.g. if the
+ request URI contains incorrect query parameters or a syntactically
+ incorrect payload body), 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 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.
+
+ ---
+
+ 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '401':
+ description: >
+ 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:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ 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.
+ type: string
+ maximum: 1
+ minimum: 0
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '403':
+ description: >
+ 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:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '404':
+ description: >
+ 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.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '405':
+ description: >
+ 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 in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '406':
+ description: >
+ 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 in that case.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '409':
+ description: >
+ Conflict
+
+ Another request is in progress that prohibits the fulfilment of the
+ current request, or the current resource state is inconsistent with
+ the request.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '412':
+ description: >
+ Precondition Failed
+
+ 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:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '416':
+ description: >
+ Requested Range Not Satisfiable
+
+ This code is returned if the requested byte range in the Range HTTP
+ header is not present in the requested resource.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '422':
+ description: >
+ 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. NOTE 2:
+ This error response code is only applicable for methods that have a
+ request body.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '500':
+ description: >
+ 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 withthis response code.
+ The "ProblemDetails" structure shall be provided, and shall include
+ in the "detail" attribute more information about the source of the
+ problem.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+ '503':
+ description: >
+ 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 [13] for
+ the use of the "Retry-After" HTTP header and for the alternative to
+ refuse the connection. The "ProblemDetails" structure may be
+ omitted.
+ headers:
+ Content-Type:
+ description: The MIME type of the body of the response.
+ type: string
+ maximum: 1
+ minimum: 1
+ schema:
+ 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].
+ type: object
+ required:
+ - status
+ - detail
+ properties:
+ type:
+ 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".
+ type: string
+ format: URI
+ title:
+ 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).
+ type: string
+ status:
+ 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.
+ type: integer
+ detail:
+ description: >
+ A human-readable explanation specific to this occurrence of
+ the problem.
+ type: string
+ instance:
+ description: >
+ A URI reference that identifies the specific occurrence of the
+ problem. It may yield further information if dereferenced.
+ type: string
+ format: URI
+definitions:
+ VnfConfiguration:
+ description: >
+ This type represents configuration parameters of a VNF instance and its
+ VNFC instances.
+ type: object
+ required:
+ - vnfConfigurationData
+ properties:
+ vnfConfigurationData:
+ description: |
+ This type represents configuration parameters of a VNF instance.
+ type: object
+ properties:
+ extCpConfig:
+ description: |
+ This type represents configuration parameters of a CP instance.
+ type: object
+ required:
+ - cpId
+ - cpdId
+ - addresses
+ properties:
+ cpId:
+ description: >
+ An identifier that is unique for the respective type within a
+ VNF instance, but may not be globally unique.
+ type: string
+ cpdId:
+ description: |
+ An identifier that is unique within a VNF descriptor.
+ type: string
+ addresses:
+ description: |
+ Network address and port assigned to the CP.
+ type: array
+ items:
+ 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.
+ type: object
+ properties:
+ address:
+ description: >
+ Network address that has been configured on the CP. See
+ NOTE 1.
+ type: object
+ properties:
+ macAddress:
+ description: >
+ A MAC address. Representation: string that consists
+ of groups of two hexadecimal digits, separated by
+ hyphens or colons.
+ type: string
+ format: MAC
+ ipAddress:
+ 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.
+ type: string
+ format: IP
+ useDynamicAddress:
+ description: >
+ Set to true if an address shall be assigned dynamically.
+ Otherwise set to false. The default value shall be
+ false. See NOTE 1.
+ type: boolean
+ port:
+ description: >
+ The port assigned to the CP instance (e.g. IP port
+ number, Ethernet port number, etc.).
+ type: integer
+ dhcpServer:
+ 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.
+ type: string
+ format: IP
+ vnfSpecificData:
+ 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 key- value
+ pairs is represented as an object. It shall comply with the
+ provisions defined in clause 4 of IETF RFC 7159.
+ type: object
+ vnfcConfigurationData:
+ description: |
+ Configuration parameters of the VNFC instances.
+ type: array
+ items:
+ description: |
+ This type represents configuration parameters of a VNFC instance.
+ type: object
+ required:
+ - vnfcInstanceId
+ properties:
+ vnfcInstanceId:
+ description: >
+ An identifier that is unique for the respective type within a
+ VNF instance, but may not be globally unique.
+ type: string
+ intCpConfig:
+ description: >
+ Configuration parameters for the internal CPs of the VNFC
+ instance.
+ type: array
+ items:
+ description: >
+ This type represents configuration parameters of a CP
+ instance.
+ type: object
+ required:
+ - cpId
+ - cpdId
+ - addresses
+ properties:
+ cpId:
+ description: >
+ An identifier that is unique for the respective type
+ within a VNF instance, but may not be globally unique.
+ type: string
+ cpdId:
+ description: |
+ An identifier that is unique within a VNF descriptor.
+ type: string
+ addresses:
+ description: |
+ Network address and port assigned to the CP.
+ type: array
+ items:
+ 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.
+ type: object
+ properties:
+ address:
+ description: >
+ Network address that has been configured on the CP.
+ See NOTE 1.
+ type: object
+ properties:
+ macAddress:
+ description: >
+ A MAC address. Representation: string that
+ consists of groups of two hexadecimal digits,
+ separated by hyphens or colons.
+ type: string
+ format: MAC
+ ipAddress:
+ 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.
+ type: string
+ format: IP
+ useDynamicAddress:
+ description: >
+ Set to true if an address shall be assigned
+ dynamically. Otherwise set to false. The default
+ value shall be false. See NOTE 1.
+ type: boolean
+ port:
+ description: >
+ The port assigned to the CP instance (e.g. IP port
+ number, Ethernet port number, etc.).
+ type: integer
+ dhcpServer:
+ 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.
+ type: string
+ format: IP
+ vnfcSpecificData:
+ 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 key-
+ value pairs is represented as an object. It shall comply with
+ the provisions defined in clause 4 of IETF RFC 7159.
+ type: object
+ VnfConfigModifications:
+ 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.
+ type: object
+ properties:
+ vnfConfigurationData:
+ description: |
+ This type represents configuration parameters of a VNF instance.
+ type: object
+ properties:
+ extCpConfig:
+ description: |
+ This type represents configuration parameters of a CP instance.
+ type: object
+ required:
+ - cpId
+ - cpdId
+ - addresses
+ properties:
+ cpId:
+ description: >
+ An identifier that is unique for the respective type within a
+ VNF instance, but may not be globally unique.
+ type: string
+ cpdId:
+ description: |
+ An identifier that is unique within a VNF descriptor.
+ type: string
+ addresses:
+ description: |
+ Network address and port assigned to the CP.
+ type: array
+ items:
+ 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.
+ type: object
+ properties:
+ address:
+ description: >
+ Network address that has been configured on the CP. See
+ NOTE 1.
+ type: object
+ properties:
+ macAddress:
+ description: >
+ A MAC address. Representation: string that consists
+ of groups of two hexadecimal digits, separated by
+ hyphens or colons.
+ type: string
+ format: MAC
+ ipAddress:
+ 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.
+ type: string
+ format: IP
+ useDynamicAddress:
+ description: >
+ Set to true if an address shall be assigned dynamically.
+ Otherwise set to false. The default value shall be
+ false. See NOTE 1.
+ type: boolean
+ port:
+ description: >
+ The port assigned to the CP instance (e.g. IP port
+ number, Ethernet port number, etc.).
+ type: integer
+ dhcpServer:
+ 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.
+ type: string
+ format: IP
+ vnfSpecificData:
+ 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 key- value
+ pairs is represented as an object. It shall comply with the
+ provisions defined in clause 4 of IETF RFC 7159.
+ type: object
+ vnfcConfigurationData:
+ 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 ).
+ type: array
+ items:
+ description: |
+ This type represents configuration parameters of a VNFC instance.
+ type: object
+ required:
+ - vnfcInstanceId
+ properties:
+ vnfcInstanceId:
+ description: >
+ An identifier that is unique for the respective type within a
+ VNF instance, but may not be globally unique.
+ type: string
+ intCpConfig:
+ description: >
+ Configuration parameters for the internal CPs of the VNFC
+ instance.
+ type: array
+ items:
+ description: >
+ This type represents configuration parameters of a CP
+ instance.
+ type: object
+ required:
+ - cpId
+ - cpdId
+ - addresses
+ properties:
+ cpId:
+ description: >
+ An identifier that is unique for the respective type
+ within a VNF instance, but may not be globally unique.
+ type: string
+ cpdId:
+ description: |
+ An identifier that is unique within a VNF descriptor.
+ type: string
+ addresses:
+ description: |
+ Network address and port assigned to the CP.
+ type: array
+ items:
+ 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.
+ type: object
+ properties:
+ address:
+ description: >
+ Network address that has been configured on the CP.
+ See NOTE 1.
+ type: object
+ properties:
+ macAddress:
+ description: >
+ A MAC address. Representation: string that
+ consists of groups of two hexadecimal digits,
+ separated by hyphens or colons.
+ type: string
+ format: MAC
+ ipAddress:
+ 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.
+ type: string
+ format: IP
+ useDynamicAddress:
+ description: >
+ Set to true if an address shall be assigned
+ dynamically. Otherwise set to false. The default
+ value shall be false. See NOTE 1.
+ type: boolean
+ port:
+ description: >
+ The port assigned to the CP instance (e.g. IP port
+ number, Ethernet port number, etc.).
+ type: integer
+ dhcpServer:
+ 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.
+ type: string
+ format: IP
+ vnfcSpecificData:
+ 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 key-
+ value pairs is represented as an object. It shall comply with
+ the provisions defined in clause 4 of IETF RFC 7159.
+ type: object
+
diff --git a/SOL002/VNFConfiguration-API/jsons/vnfConfigModifications.json b/SOL002/VNFConfiguration-API/jsons/vnfConfigModifications.json
new file mode 100644
index 00000000..2863575b
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/jsons/vnfConfigModifications.json
@@ -0,0 +1,43 @@
+{
+ "vnfConfigurationData": {
+ "extCpConfig": {
+ "cpId": "string",
+ "cpdId": "string",
+ "addresses": [
+ {
+ "address": {
+ "macAddress": "string",
+ "ipAddress": "string"
+ },
+ "useDynamicAddress": true,
+ "port": 0
+ }
+ ]
+ },
+ "dhcpServer": "string",
+ "vnfSpecificData": {}
+ },
+ "vnfcConfigurationData": [
+ {
+ "vnfcInstanceId": "string",
+ "intCpConfig": [
+ {
+ "cpId": "string",
+ "cpdId": "string",
+ "addresses": [
+ {
+ "address": {
+ "macAddress": "string",
+ "ipAddress": "string"
+ },
+ "useDynamicAddress": true,
+ "port": 0
+ }
+ ]
+ }
+ ],
+ "dhcpServer": "string",
+ "vnfcSpecificData": {}
+ }
+ ]
+}
\ No newline at end of file
diff --git a/SOL002/VNFConfiguration-API/schemas/problemDetails.schema.json b/SOL002/VNFConfiguration-API/schemas/problemDetails.schema.json
new file mode 100644
index 00000000..62f17612
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/schemas/problemDetails.schema.json
@@ -0,0 +1,34 @@
+{
+ "definitions": {},
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "type": "object",
+ "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].\n",
+ "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\".\n",
+ "format": "URI"
+ },
+ "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).\n"
+ },
+ "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.\n"
+ },
+ "detail": {
+ "type": "string",
+ "description": "A human-readable explanation specific to this occurrence of the problem.\n"
+ },
+ "instance": {
+ "type": "string",
+ "description": "A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.\n",
+ "format": "URI"
+ }
+ },
+ "required": [
+ "status",
+ "detail"
+ ]
+}
\ No newline at end of file
diff --git a/SOL002/VNFConfiguration-API/schemas/vnfConfigModifications.schema.json b/SOL002/VNFConfiguration-API/schemas/vnfConfigModifications.schema.json
new file mode 100644
index 00000000..8545bb29
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/schemas/vnfConfigModifications.schema.json
@@ -0,0 +1,157 @@
+{
+ "description": "This type represents request parameters for the \"Set Configuration\" operation. * NOTE 1: At least one of \"vnfConfigurationData\" and \"vnfcConfigurationData\"\n shall be present.\n * NOTE 2: The VnfcConfiguration data type can only be used to modify the configuration\n of existing VNFC instances.\n",
+ "type": "object",
+ "properties": {
+ "vnfConfigurationData": {
+ "description": "This type represents configuration parameters of a VNF instance.\n",
+ "type": "object",
+ "properties": {
+ "extCpConfig": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ },
+ "vnfcConfigurationData": {
+ "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\".\n Assumptions:\n 1) \"oldList\" is the \"VnfcConfigurationData\" array to be modified and \"newList\"\n is the \"VnfcConfigurationData\" array that contains the changes.\n 2) \"oldEntry\" is an entry in \"oldList\" and \"newEntry\" is an entry in \"newList\".\n 3) A \"newEntry\" has a \"corresponding entry\" if there exists an \"oldEntry\" that \n has the same content of the \"vnfcInstanceId\" attribute as the \"newEntry\"; \n a \"newEntry\" has no corresponding entry if no such \"oldEntry\" exists.\n 4) In any array of \"VnfcConfigurationData\" structures, the content of \"vnfcInstanceId\"\n is unique (i.e. there shall be no two entries with the same content of \"vnfcInstanceId\").\n Provisions:\n 1) For each \"newEntry\" in \"newList\" that has no corresponding entry in \"oldList\", \n the \"oldList\" array shall be modified by adding that \"newEntry\".\n\n 2) For each \"newEntry\" in \"newList\" that has a corresponding \"oldEntry\" in \"oldList\",\n the value of \"oldEntry\" shall be updated with the value of \"newEntry\" according to\n the rules of JSON Merge PATCH (see IETF RFC 7396 ).\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a VNFC instance.\n",
+ "type": "object",
+ "required": [
+ "vnfcInstanceId"
+ ],
+ "properties": {
+ "vnfcInstanceId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "intCpConfig": {
+ "description": "Configuration parameters for the internal CPs of the VNFC instance.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfcSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/SOL002/VNFConfiguration-API/schemas/vnfConfiguration.schema.json b/SOL002/VNFConfiguration-API/schemas/vnfConfiguration.schema.json
new file mode 100644
index 00000000..1156069c
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/schemas/vnfConfiguration.schema.json
@@ -0,0 +1,160 @@
+{
+ "description": "This type represents configuration parameters of a VNF instance and its VNFC instances.\n",
+ "type": "object",
+ "required": [
+ "vnfConfigurationData"
+ ],
+ "properties": {
+ "vnfConfigurationData": {
+ "description": "This type represents configuration parameters of a VNF instance.\n",
+ "type": "object",
+ "properties": {
+ "extCpConfig": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ },
+ "vnfcConfigurationData": {
+ "description": "Configuration parameters of the VNFC instances.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a VNFC instance.\n",
+ "type": "object",
+ "required": [
+ "vnfcInstanceId"
+ ],
+ "properties": {
+ "vnfcInstanceId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "intCpConfig": {
+ "description": "Configuration parameters for the internal CPs of the VNFC instance.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance.\n",
+ "type": "object",
+ "required": [
+ "cpId",
+ "cpdId",
+ "addresses"
+ ],
+ "properties": {
+ "cpId": {
+ "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
+ "type": "string"
+ },
+ "cpdId": {
+ "description": "An identifier that is unique within a VNF descriptor.\n",
+ "type": "string"
+ },
+ "addresses": {
+ "description": "Network address and port assigned to the CP.\n",
+ "type": "array",
+ "items": {
+ "description": "This type represents configuration parameters of a CP instance address. * NOTE 1: Either \"address\" or \"useDynamicAddress\" shall be present.\n * NOTE 2: At least one of \"macAddress\" and \"ipAddress\" shall be present.\n",
+ "type": "object",
+ "properties": {
+ "address": {
+ "description": "Network address that has been configured on the CP. See NOTE 1.\n",
+ "type": "object",
+ "properties": {
+ "macAddress": {
+ "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n",
+ "type": "string",
+ "format": "MAC"
+ },
+ "ipAddress": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ }
+ }
+ },
+ "useDynamicAddress": {
+ "description": "Set to true if an address shall be assigned dynamically. Otherwise set to false. The default value shall be false. See NOTE 1.\n",
+ "type": "boolean"
+ },
+ "port": {
+ "description": "The port assigned to the CP instance (e.g. IP port number, Ethernet port number, etc.).\n",
+ "type": "integer"
+ }
+ }
+ }
+ }
+ }
+ }
+ },
+ "dhcpServer": {
+ "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.\n",
+ "type": "string",
+ "format": "IP"
+ },
+ "vnfcSpecificData": {
+ "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 key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.\n",
+ "type": "object"
+ }
+ }
+ }
+ }
+ }
+}
\ No newline at end of file
diff --git a/SOL002/VNFConfiguration-API/variables.txt b/SOL002/VNFConfiguration-API/variables.txt
new file mode 100644
index 00000000..dea21804
--- /dev/null
+++ b/SOL002/VNFConfiguration-API/variables.txt
@@ -0,0 +1,42 @@
+*** Variables ***
+${VNFM_HOST} localhost # Hostname of the VNFM
+${VNFM_PORT} 8080 # Listening port of the VNFM
+${VNF_HOST} localhost # Hostname of the NFVO
+${VNF_PORT} 8081 # Listening port of the NFVO
+${VNFM_SCHEMA} https
+${VNF_SCHEMA} https
+${AUTHORIZATION} Bearer QWxhZGRpbjpvcGVuIHNlc2FtZQ==
+${CONTENT_TYPE} application/json
+${CONTENT_TYPE_PATCH} application/merge-patch+json
+${ACCEPT} application/json
+${apiRoot} /
+${apiName} vnfconfig
+${apiVersion} v1
+${AUTH_USAGE} 1
+${WRONG_AUTHORIZATION} Bearer XXXXXWRONGXXXXX
+${alarm_filter} managedObjectId
+${managedObjectId} 007c111c-38a1-42c0-a666-7475ecb1567c
+${invalid_alarm_filter} badFilter
+${alarmId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
+${vnfInstanceDescription} description vnf
+${vnfInstanceDescription_Update} Updated description vnf
+${SINGLE_FILE_VNFD} 1 # If VNFD is PLAIN TEXT
+${ACCEPT_PLAIN} text/plain
+${ACCEPT_ZIP} application/zip
+${vnfPkgId_processing} 007c111c-38a1-42c0-a666-7475ecb1567c
+${ARTIFACT_TYPE} application/octet-stream
+${ARTIFACT_ID} artifactId
+${WRONG_ACCEPT} application/json
+${vnfLcmOpOccId} 6fc3539c-e602-4afa-8e13-962fb5a7d81d
+${CancelMode} GRACEFUL
+${LccnSubscriptionRequest} {}
+${NVFM_DUPLICATION} 0
+${sub_filter} filter
+${sub_filter_invalid} filter_invalid
+${subscriptionId} 6fc3539c-e602-4afa-8e13-962fb5a7d81f
+${notification_ep} /notification
+${notification_port} 9091
+${AlarmNotification} {}
+${AlarmClearedNotification} {}
+${AlarmListRebuiltNotification} {}
+${PerceivedSeverity} CRITICAL
\ No newline at end of file
--
GitLab